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Foreword 




he process of planning and implementing a financial management system is 
a complex one, with numerous participants, myriad considerations to 
address, and long-term implications. Colleges and universities must meet the 
challenges of increased performance accountability, cost containment, and 



higher productivity. We are pleased to be able to offer this handbook as a guide to help 
chief executive officers and other executive decision-makers navigate through the 
decisions as well as the planning and implementation process itself. 

Among the many helpful recommendations of this handbook, two are worth empha- 
sizing here. First, there is no single formula that can lead to success. This handbook 
stresses the importance of devising the most appropriate strategy for meeting your 
institution's unique and specific needs. 

Second, meeting the challenges successfully requires a strategy based on teamwork 
and partnership — which are much more often applauded in theory than observed in 
practice. Our culture's popular arts don't celebrate the "glamour" of collaboration, let 
alone its necessity. At every step in the development of this project, and in the product 
itself, we have sought to emphasize the need for real and continuing partnerships. 
Effective use of this handbook also requires a partnership between financial executives 
and information resources management executives. 

NACUBO and CAUSE are grateful to the authors for this thorough, valuable contribu- 
tion to the field of higher education management. We believe this handbook can be an 
indispensable tool for both veteran and newly appointed financial officers and informa- 
tion technology managers in understanding the process and grappling with the chal- 
lenges of making financial management decisions for the future. A noteworthy attribute 
of this handbook is the applicability of the process described herein to any type of 
system implementation, financial or otherwise. 

Given the increasing complexity of the rapidly changing technology landscape, 
NACUBO and CAUSE look forward to continued work as partners to provide additional 
information and assistance to enable our institutions' leaders to craft the best possible 
decisions, informed by the thinking of some of the best minds in our collective commu- 
nities. 



James E. Morley Jr. 

President 

NACUBO 



Jane N. Ryland 

President 

CAUSE 
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Preface 




n April 1993, the National Association of 
College and University Business Officers 
formed the Financial Information 
Systems Subcommittee. The members of 
this group observed that many colleges and universi- 
ties were in the midst of or considering the acquisi- 
tion or development of new financial systems. 

The subcommittee's discussions noted that at 
least five fundamental changes in the basic character 
and nature of information technology were likely to 
influence; in important ways ; the manner in which 
new financial systems should be evaluated, selected, 
and developed or purchased. These changes include: 
(1) the increasing roles of campus networks and the 
Internet; (2) the emergence of distributed hardware 
and software platforms; (3) the emergence of 
graphical user interfaces; (4) the emergence of new 
information distribution and access approaches (e.g., 
World Wide Web) and new tools for information 
analysis and decision support; and (5) the increasing 
viability of robust electronic commerce. 

Against this technological backdrop, the sub- 
committee also observed that fundamental changes 
in the administrative operations of many U.S. 
colleges and universities were taking place. The first 
half of this decade has witnessed increasing public 
skepticism, declining enrollments in many geo- 
graphic areas, and sharp declines in state support for 
many public universities. Additionally, current 
pressures to reduce the federal deficit suggest that 
the late 1990s will witness broad reductions in 
federal support of higher education, particularly of 
university-based research. Finally, the subcommittee 
noted that a few colleges and universities were 
experimenting with the financial system planning, 
selection, and implementation process itself, explor- 
ing new partnerships with software vendors and 
other colleges and universities. 

These observations led subcommittee members 
to conclude that an important need would be filled 
by commissioning a practitioner's handbook to help 
guide college and university business officers 
through the complex set of decisions and actions 
associated with replacing financial management 
systems. 

O 
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To fill this need, NACUBO asked several leaders 
in college and university management to "develop a 
publication that addresses, in a 'how-to' format, the 
steps necessary to evaluate an institution's current 
hardware, network, and software." As authors of this 
book, we were asked, further, to identify change 
strategies that would support both incremental 
changes in financial systems and large scale changes 
in the institution's "financial architecture." Finally, 
we were asked to identify themes, messages, and 
strategies that would assist campus practitioners 
across the entire higher education constellation, 
from small liberal arts college to community college 
to research university. 

Most importantly, an early decision was made to 
produce this book as a collaboration between 
NACUBO and CAUSE, the association for managing 
and using information resources in higher educa- 
tion. This collaboration reflects our universal belief 
that the successful implementation of new financial 
information systems depends on a strong and 
healthy partnership between financial management 
and information technology management. 

Our group of authors reflects broad and varied 
experience and expertise in financial and technology 
management. We are technologists, financial offic- 
ers, planners, and generalists, who brought to the 
writing experience rich and varied professional 
backgrounds representing a broad spectrum of 
perspectives — from liberal arts to community 
college, from public research university to the Ivy 
League, and from an international association. 

We sincerely hope that the book we have 
developed reflects the benefits of this professional 
and contextual diversity and reflects the mutual 
learning (without the occasional learning pain!) that 
we have shared in this writing experience. 

Stephen Jonas 
Richard N. Katz 
Linda Martinson 
Margaret F. Plympton 
Steven W. Relyea 
Edwin D. Rennie 
Julia A. Rudy 
John F. "Barry" Walsh 
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Chapter I 
Overview 



♦ Understanding the Context 

♦ To Thine Own Self Be True: 

Financial Systems and Practices 

♦ New Technology and the Need to Rethink 
Project Roles 

♦ New Options for the '90s — Partnering 

♦ Emphasis on People and Process 



“In the 1990s and beyond, the 
pervasiveness of an institution's 
financial system — and its 
interconnection with other key systems 
and the campuswide network — 
highlight more than ever the need to 
integrate thinking about the 
institution's financial management 
model with its academic vision, strategy, 
and delivery system." 



O 

ERIC 



10 




I: Introduction 



n addition to the major changes that are 
occurring in the technology environ- 
ment, college and university leaders 
charged with planning and implement- 
ing financial management systems for the future 
must also contend with a number of changes 
affecting higher education administration in the 
'90s. 

Understanding the Context 

At least five issues are altering dramatically the 
context for financial systems planning: (1) calls for 
increased accountability in higher education; (2) a 
changing environment that will demand flexible 
new systems; (3) increasing pressures for efficiency 
and productivity in colleges and universities; (4) the 
mandate for improved service quality in higher 
education; and (5) the importance of involving the 
broad campus community in the planning process. 

Accountability 

Increasing public skepticism of higher educa- 
tion has manifested itself, in part, in calls for 
increased accountability and academic effectiveness. 
These calls have, in turn, found expression in the 
creation of myriad new financial accounting and 
reporting requirements. In general, these new 
requirements call for more information, more 
frequent reporting, more conformance with gener- 
ally accepted accounting practices (GAAP), and 
more disclosure of budgetary as well as expenditure 
information. The demands that these requirements 
are placing on most of higher education's installed 
base of financial information systems were not 
anticipated by the designers of those systems. 



associated systems. For example, as institutions look 
forward to the redesign of the accounts receivable 
processes, they will likely want integration between 
the financial system and components of their 
student system — such as financial aid, housing, and 
registration. There also will be a desire to provide 
the necessary flexibility to integrate the financial 
system with ancillary or feeder systems such as the 
storehouse, bookstore, or telecommunications 
billing systems. Such integration will improve the 
timeliness of information being fed into the finan- 
cial system. 

At an early stage in the project, the institution 
should determine how this integration will take 
place, e.g., whether it is cost effective to develop or 
acquire new student and human resources systems 
concurrently with, or as a part of, a new financial 
system project. This decision should depend not 
only on the desirability of such integration, but on 
the institution's ability to manage effectively the 
increased project scope and complexity that such a 
decision would bring about. 

While every college or university should be 
prepared to address the question of how broad the 
scope of the system project should be, this book 
focuses on the issues surrounding financial systems. 
The process outlined, however, can also be used by 
institutions that wish to plan for and implement a 
set of integrated systems. 

Integration comes at a price. Integrated systems 
tend to be much more complex than modular 
systems and, therefore, demand more resources to 
design, develop, and support. This added complex- 
ity may also make it more difficult to migrate highly 
integrated and customized systems to evolving 
technology architectures in the future. 




Flexibility Efficiency and productivity 

Flexible financial systems should also be capable Calls for increased efficiency have found expres- 

of providing an appropriate level of integration with sion in a variety of changes in many college and 
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university business and finance programs and 
practices. Such changes include organizational 
restructurings, early retirement programs, quality 
improvement programs, program curtailments, and 
reengineering efforts. These changes have also 
added urgency to higher education's look at its 
underlying financial information systems. On many 
campuses, early retirements and other staff reduc- 
tions have depleted the staff talent pool. In cases 
where senior employees have not been replaced — 
while campus financial activity has remained 
constant or increased — many college and university 
business officers face higher risks of transaction 
error or internal control failures. 

In other cases, efforts to redesign business and 
financial processes have been constrained by 
existing financial systems that have automated old 
vertical functions, such as purchasing and disburse- 
ments, and that cannot deliver the desired institu- 
tional efficiencies without wholesale redesign or 
replacement. In all cases, the pressures for increased 
efficiency are fueling institutional needs for more 
and better information, both to monitor and control 
budgets and expenditures and to plan and forecast 
financial activity. The satisfaction of these needs, 
too, is being constrained and limited by existing 
financial systems. 

Service quality 

Calls for increased client service have found 
expression not only in a wide variety of plans, 
strategies, and programs to enhance the quality of 
teaching and research, but also in a similarly rich 
variety of business and finance activities designed to 
enhance the service quality of higher education 
administration. The programs include the imple- 
mentation of integrated voice response (IVR) sys- 
tems for registration or benefit enrollments; elec- 
tronic deposit for employee paychecks and vendor 
payments; the implementation of all-in-one cards to 
support student and faculty access to campus 
services; the deployment of Internet "home page" 
directories of campus services; and many others. 
These pressures, too, fuel increasing expectations of 
the institution's financial services and the systems 
that support these services. 

Inclusiveness 

Given the collegial aspects of higher education 
governance, success in any major college or univer- 



sity project depends on multilateral participation 
with faculty, students, and other key stakeholders. In 
many ways, the unique impulse in higher education 
to consult broadly, to engage in critical exchange, 
and to respect diverse opinions is the wellspring of 
our industry's ability to renew itself continually. 

This same impulse is also a potential source of 
contention, project delays, fragmented decision- 
making, and project overhead which can put such 
projects at risk, as well as serve as a continual source 
of consternation to our industrial business partners. 
While achieving an effective balance between 
broad-based, institution-wide consultation, collabo- 
ration, and communication and tight project control 
is more art than science, the need to do so is dis- 
cussed explicitly and is a current that runs through- 
out this book. 

To Thine Own Self Be True: 

Financial Systems and Practices 

If indeed there can be a universal prescription that 
applies equally to all elements of higher education, 
it is that one must not divorce the financial system 
from the intended institutional financial manage- 
ment model. This notion is analogous, but not 
identical, to the process of defining requirements 
that is an accepted component of the structured 
analysis used to specify the financial systems of the 
1970s. In the 1990s and beyond, the pervasiveness of 
an institution's financial system — and its intercon- 
nection with other key systems and the campuswide 
network — highlight more than ever the need to 
integrate thinking about the institution's financial 
management model with its academic vision, 
strategy, and delivery system. For example, a multi- 
site, instruction-oriented institution that focuses on 
part-time degree seekers — such as the University of 
Phoenix — will organize its financial environment 
and systems differently from, for example, a univer- 
sity with a medical center and large auxiliary 
enterprises or a small private college with a predomi- 
nantly residential student body. 

The process of reconciling the high-level design 
and architecture of the financial system with the 
academic and business model of the institution is 
made more challenging by the dynamic nature of 
higher education in the 1990s. The external forces 
shaping today's decision-making context are creat- 
ing a set of options that could not have been 
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considered — on technical grounds alone — 25 years 
ago. Today's decision-maker has a range of options 
that is at once gratifying and potentially overwhelm- 
ing, and, more important, a cast of stakeholders that 
is diverse, interested, computer literate, and influen- 
tial. This is a good news-bad news story. 

In the 1970s, financial transactions and financial 
analysis depended on the same system. Large 
campus financial systems demanded mainframes 
and/or minicomputers, and design decisions were 
often based on factors related to computing re- 
source availability and software maintainability. For 
these reasons, these systems, in spite of frequent 
protestations to the contrary, typically drove our 
financial practices and operations, rather than the 
other way around. The introduction of the personal 
computer, dramatic improvements in computing 
price/performance, growth of campuswide net- 
works, and progress in distributed computing 
architectures have changed all of this. 

The good news is that colleges and universities 
now have much greater freedom — financially and 
technically — to reinvent their financial practices. 
Many institutions are doing so. The University of 
Pennsylvania, Indiana University, University of 
Southern California, UCLA, Cornell University, and 
other large research universities have moved or are 
moving toward responsibility center management, a 
distributed financial accountability model that 
depends on distributed financial information. 

College and university trustees, bond underwrit- 
ers, bankers, and public officials are seeking, for 
different reasons, to provide meaningful financial 
comparisons among institutions of higher learning, 
creating tensions between the traditional fund- 
oriented reporting model of the Governmental 
Accounting Standards Board (GASB) and the entity- 
oriented model required under the Financial Ac- 
counting Standards Board (FASB). (The challenges 
are especially daunting for an institution using a 
GASB model that wants to consolidate component 
units based on FASB standards and completely 
eliminate inter-entity transactions.) To these pres- 
sures are added those related to new cost accounting 
requirements under the federal Cost Accounting 
Standards Board (CASB). 

Colleges and universities across the continent 
have reengineered various financial processes, such 
as purchasing and disbursements, and have begun to 
implement new information systems to support 
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these redesigned processes. Many institutions (such 
as the University of California, University of Dela- 
ware, and Pennsylvania State University) have 
focused attention on reducing the paperwork 
associated with financial activity and have set goals 
for eliminating paper-based paychecks, invoices, 
receivables, and other intermediaries of financial 
transactions. 

Different intentions regarding an institution's 
financial operating environment suggest different 
approaches and different technologies. For example, 
a priority placed on the long-term elimination of 
paper will focus institutional attention in the 
planning process on strategies such as business 
alliances and on technologies such as electronic 
funds transfer, electronic document interchange, 
and internal electronic transaction forms. The 
pressure to eliminate paper as a financial intermedi- 
ary will rise as authentication and security services 
on networks make it possible for people to identify 
suppliers and products, and order and pay electroni- 
cally for goods and services (admissions, library 
materials and fines, office supplies, etc.). 

The bad news, of course, is that the imposition 
of new regulations and reporting requirements and 
the redesign of financial processes can be difficult, 
risky, and costly. The implementation of these new 
capabilities can be even riskier, more difficult, and 
more costly, and the systems needed to support 
them can also be complex and expensive. 

In the 1970s, centralized computing architec- 
tures and the economics of computing influenced 
the evolution of a typically centralized financial 
management environment. The financial officer 
specified requirements to the administrative infor- 
mation systems office and was either satisfied with 
the project outcomes, or not. The negotiation over 
system features and costs was mediated through a 
structured process, such as the systems development 
life-cycle model. Decisions typically balanced the 
needs of the financial office for service, on one 
hand, with the technical and financial constraints 
posed by the administrative information systems 
office, on the other. The needs of the financial office 
revolved around controlling financial processes, 
maintaining the general ledger, issuing vendor 
checks, and the like. Rarely were such systems 
designed to meet the planning, monitoring, and 
controlling requirements posed, for example, by 
complex auxiliary operations or the contract- 
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intensive academic programs found at research 
universities. Since the intended users of these 
systems were typically professionals in the account- 
ing office who used them intensively and exten- 
sively, the demands and expectations placed on these 
systems with respect to "user friendliness" were 
often modest. The failure of many such systems to 
meet the planning and operational needs of institu- 
tional subunits in a user-friendly fashion has con- 
tributed to the proliferation of "shadow systems" in 
these subunits. 

New Technology and the Need to 
Rethink Project Roles 

The proliferation of "shadow systems" throughout 
the institution has helped address the concerns over 
functionality and ease of use raised in local aca- 
demic units and auxiliaries. In doing so, however, 
these systems have greatly complicated accounting 
and financial reporting at the institutional level, 
have fostered concerns and problems regarding data 
quality and synchronization, have created tensions 
between central organizations and the local units 
they support, have spawned control issues, and have 
contributed to varying amounts of workload dupli- 
cation across the institution. These issues and 
concerns have played out, in varying degrees, at 
higher education institutions across the country, as 
well as in the private sector. 

In essence, the proliferation of personal comput- 
ers, the widespread influence of the campuswide 
network, and the use of spreadsheets and desktop 
financial packages have heightened and broadened 
interest in financial information systems. This 
increased awareness and the growth of computer 
and financial literacy across the institution are 
reshaping the roles and politics of the financial 
system design process. Financial information 
systems, in general, can no longer be developed 
exclusively through the bilateral agreement of the 
institution's chief financial officer and chief infor- 
mation technology officer. Under today's condi- 
tions, the support of these key decision-makers is 
likely to be a necessary but insufficient condition of 
project success. 

While it is perhaps easy to point to the need to 
change the project and organizational structures and 
roles that are needed to support the design of new 
financial systems, it is not easy to elucidate these 



new roles or structures. On many levels, the answer 
to these questions is "it depends." The roles, project 
architecture, ownership, and other key aspects of 
planning and implementing financial management 
systems depend on what changes the institution is 
seeking, who is seeking the change, who commands 
which institutional resources, and who, in the final 
analysis, will really step up to the mark and provide 
project leadership. 

As long as computing cycles and accessibility 
were scarce resources, the natural leadership of 
projects of this nature often fell to the institution's 
technology chief. In the current environment of 
networked computing and diminishing higher 
education resources, financial managers throughout 
the institution have an increased stake in the 
performance and capabilities of the financial infor- 
mation system and are likely to be more interested 
in and capable of assuming or sharing the leadership 
of these projects. In fact, some central financial 
organizations now assume the direct responsibility 
for providing information systems support. 

There is no absolutely right or wrong answer to 
the question of how to balance project responsibil- 
ity. The essential message of this book is that this 
balance of perspectives, skills, and ownership is 
central to the vitality and success of the project. For 
this reason, much of the book is devoted to identify- 
ing structures and approaches to balancing project 
responsibilities that can be shaped and adapted by 
readers to accommodate institutional differences in 
complexity, objectives, leadership, funding, and 
other key project success factors. 

New Options for the '90s — Partnering 

Just as the changes in higher education's climate, 
operating practices, and information technology 
base have changed the nature of the internal col- 
laboration on systems projects, these factors have 
also altered the options that colleges and universities 
will face with respect to external collaboration. 

While in the past the options facing systems 
planners revolved around the decision of whether to 
buy an "off-the-shelf" package or to build a system 
in-house "from scratch," in the late 1990s and 
beyond the decision is rarely likely to be bipolar. 
Today, the costs and complexity of implementing 
new systems suggest the need to ask, "With whom 
will I need to partner?" 




Instead of choosing among decisions at the 
"build or buy" extremes, today's decision-makers are 
increasingly faced with a continuum of partnership 
options, whether building or buying. These include 
co-developing new software with an industry 
partner, customizing (to a lesser or greater extent) 
existing packaged software in-house with an indus- 
try partner, and developing software with multiple 
industry and/or institutional partners as part of a 
broad collaborative effort. In-house development of 
applications also involves a partnership — between 
internal information systems professionals and staff 
in the business office and other finance areas. 

In many ways the decisions about whether to 
partner, with whom to partner, and how to manage 
joint ventures represent the moments of truth for 
any project of this kind. The effective conduct of 
business alliances and partnerships is a critical 
determinant of success or failure for those who 
choose this option. This is a complex topic and is 
largely outside the scope of this book. We encourage 
you under all conditions to cultivate at your institu- 
tion those skills related to administering complex 
agreements and multi-lateral partnerships. 

Emphasis on People and Process 

The methods, techniques, and structures that this 
book describes are independent of the desired 
institution-wide information technology or business 
architecture, and are designed to enhance the 
institutional decision process. When successful, 
such methods, techniques, and structures enhance 
not only the quality of technical and business 
design decisions, but improve the likelihood that the 
key members of the institutional community — who 
later will judge and depend on the eventual system 
solution — will share a sense of responsibility in 
major project decisions and outcomes. 

For this reason, this book recommends using a 
team structure to bring diverse interests and exper- 
tise throughout the institution together in an 
organized fashion. As with all complex projects, the 
key to success remains the quality, organizational 
placement, credibility, and availability of project 
participants, especially the project management. 

The effective deployment of functional teams 
accomplishes the tasks of: 

• breaking the project into components of man- 
ageable and well-defined scope, 
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* identifying clear deliverables and project 
accountabilities, 

* creating a hierarchy of roles that strives to align 
project decisions vertically and horizontally 
across the institution, and 

* making it possible to compress the project in 
time by facilitating concurrent team activities. 
Having the right structures and people in place 

makes it possible to lay out the steps in a complex 
project in ways that convey to every participant and 
key stakeholder what is to be expected and when. 

The endeavor can be viewed as having five 
major phases: (1) articulating a strategic framework, 
(2) structuring and managing the project, (3) 
determining business and technology requirements, 
(4) selecting a solution, and (5) acquiring and 
implementing the system. Within these phases many 
steps will need to be taken and many tasks com- > 
pleted; these are graphically illustrated by process 
flow charts at the end of Chapters 2 and 3. High- 
lighted at the close of each chapter are a number of 
actions that can either greatly enhance or jeopardize 
the success of the project. Actions that are greatly 
encouraged and that seem to predispose projects 
toward success are referred to as critical success 
factors. In many cases, the failure to take a critical 
action, at a critical juncture of the project, creates 
added project risks. Such failures to act, as well as 
ill-conceived actions, are referred to as land mines. 
Finally, a glossary of terms and concepts is provided 
in Appendix B, to support the technology "aware- 
ness-raising" process described in Chapter 4. 

o book of this kind can be as prescrip- 
tive as a cookbook, because no set of 
financial management needs is likely to 
be a standard for higher education. Even 
cookbook recipes fail when the cook doubles 
specified quantities or does not take into account 
variations in humidity, altitude, or other local 
particulars. Despite this caveat, the authors believe 
that all projects of this kind have certain common 
elements and benefit from a project architecture 
that is inclusive, open, and consensus seeking. We 
hope the steps, structures, and techniques described 
in this book — and the success factors and potential 
land mines highlighted — will help you effectively 
and successfully lead, monitor, or support such 
projects at your institution. 
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II: Articulating a Strategic 
Framework 



he financial system of any college or 
university is an essential element of its 
management infrastructure. The finan- 
cial system is also a key element of the 
institution's information technology architecture. 
Thus the decision to replace, upgrade, or otherwise 
modify major components of this system should be 
viewed as being strategic to the institution. 

It is sometimes the case that while the business 
leadership of an institution is keenly aware of the 
strategic importance of the financial information 
system, the academic leadership may not view the 
financial system in such a light and may be hesitant 
to divert funds from academic programs towards 
efforts to upgrade an administrative system. Even 
when there appears to be general agreement that a 
new financial system is needed, a high-level plan- 
ning effort will be needed to evaluate the extent to 
which and how financial practices, processes, and 
systems should be changed. 

Thus the first and most critical step in planning 
a new financial system is to bring together institu- 
tional decision-makers, opinion leaders, and key 
stakeholders from diverse areas across the institu- 
tion, and from the major constituents who will be 
served by the system, to serve as a steering commit- 
tee to articulate a strategic framework for the effort 
and to provide leadership for the project. 

Creating an Effective Steering 
Committee 

To be most effective, such a steering committee 
should be sponsored and appointed by either the 
president or chancellor or by the senior executive 
officer responsible for financial operations and 
administrative systems. If this responsibility is 
divided between two senior officers, then either or 
both might sponsor the steering committee. 

As financial systems no longer support, exclu- 



sively, the financial operations of the central admin- 
istration (e.g., accounting office, purchasing, 
disbursements), the chief financial officer (CFO) 
rarely has either the organizational authority or 
political capital to lead an institution-wide financial 
initiative alone. For similar reasons, the chief 
information technology officer can rarely operate in 
isolation in making technical decisions that will 
influence campus financial practices and processes. 
In highly distributed and loosely coupled environ- 
ments, changes in the financial systems will be 
viewed as having a major impact on academic 
activities as well. Thus the leadership of the steering 
committee might come from both the CFO and 
chief technology officer in partnership. Depending 
on institutional culture, the budget officer and/or 
senior academic officer might also play leadership 
roles. 

Given the interrelationships between student 
systems and financial systems and the trend to 
distribute information access to academic depart- 
ments, high-level representatives from the student 
services office (and academic affairs if the senior 
academic officer is not co-leading the steering 
committee) will also need to be active at the strate- 

The Steering Committee's Mission 

/ Define and communicate the case for developing a 
new financial system for the institution. 

/ Establish a vision that ties together the institution's 
academic needs and aspirations with a proposed 
financial and business systems architecture. 

/ Develop a set of planning principles that will help 
define the scope and character of the project as well 
as provide the means to evaluate its outcomes. 

/ Establish, through an assessment of various 
tradeoffs, the high-level scope, boundaries, and 
priorities of the project. 
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gic level. Representatives from the institution's 
internal audit office and auxiliary enterprises should 
also be included on the steering committee. In a 
large university, business officers from major 
academic units might be steering committee mem- 
bers, as might representatives from the health 
sciences sector in institutions with medical schools 
and/or clinical facilities. 

Most colleges and universities have a great deal 
of diversity of systems, so it is also wise to ensure 
representation of different computing environments 
or platforms and to seek representation from both 
large and small units across the institution. The 
needs of units with extensive systems staff will be 
different from those with few or no such staff. The 
latter units may require financial systems that 
minimize training time, are intuitive, and provide 
many prepackaged templates and require very little 
manipulation, while larger campus organizations 
may prefer to have direct access to financial data- 
bases and may desire to customize user interfaces 
and functionality of the systems. 

The steering committee's charge should be 
stated in writing with as much specificity as pos- 
sible, including a clear statement of responsibilities 
and a suggested overall time frame. The committee 
will be the visionary and architect of the overall 
project, particularly active in the early stages. 
However, it will also play essential problem-solving, 
political, and communications roles and should 
remain "in business" throughout the project's life. 
The roles of the steering committee include: 

♦ establishing the financial architecture of the 
institution through a process of creating a 
vision and setting goals; 

♦ developing the framework for discussing poten- 
tial tradeoffs in the institution's decision to 
build or buy software or to engage in strategic 
external partnering for software development; 

♦ issuing a report to inform the institution of the 
strategic directions that have been articulated; 

♦ appointing a project manager and project 
management team and "steering" the overall 
institutional effort through implementation; 

♦ approving project plans, budgets, deliverables, 
and time lines proposed by the project manage- 
ment team; and 

♦ communicating across the institution and 
within vertical units to convey "ownership" of 
the project and project decisions. 



It may be desirable or necessary to have the 
steering committee appoint ad hoc subcommittees 
as strategic planning proceeds for the project. These 
subcommittees may focus on areas such as scanning 
the external systems environment (both at other 
institutions and in the marketplace), reviewing 
literature on higher education financial systems, 
interviewing campus customers, communicating 
findings and directions to the institutional commu- 
nity, and other areas of interest where involvement 
of the entire steering committee is not practical. 

It will also be necessary to appoint a project 
manager and project management team to carry out 
the remaining phases of the project. Like the steer- 
ing committee, the project management team may 
also find it necessary or desirable to appoint one or 
more ad hoc teams to carry out specific functions. 

In general, it will be important to distinguish 
between the two standing groups — the steering 
committee and the project management team — and 
the myriad ad hoc teams that may be needed to 
accomplish focused and specialized tasks. The 
standing groups will generally last throughout the 
duration of the project, while ad hoc groups will be 
formed to address specific tasks during the course of 
the project and will exist only as long as needed to 
accomplish those tasks (see Figure 1). 

Building the Case for Action 

While one of the first tasks of the steering commit- 
tee will be to establish a vision for the future 
financial operating environment, before undertak- 
ing that effort the committee will need to confirm 
that the institution is willing to spend significant 
resources and invest valuable staff time in a new 
financial system, and what the reasons are for 
agreeing to such an investment. 1 

Identifying the drivers for change 

The steering committee may find one or more 
of the following among the drivers for a new finan- 
cial information system: 



1 Opinions differ about whether the vision-setting pro- 
cess should precede or follow the process of making the busi- 
ness case. If you believe that a compelling vision will help to 
establish the case for change, the process of setting that vi- 
sion might come first. 



Figure 1 : 

Project roles and structure 

The scope of the project and the com- 
plexity of the institution will define the 
number and nature of standing and ad 
hoc groups that will be needed. The 
small "balls" in this figure describe 
roles to be played either by the steer- 
ing committee and the project manage- 
ment team or by specialized ad hoc 
subcommittees or teams formed to sat- 
isfy these roles. Whether formalized in 
team structures or not, these roles are 
essential elements of the overall effort. 
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Need for management information. One compel- 
ling reason for an institution to face the challenge 
of implementing a new financial system is the need 
to have reliable, accurate, timely, and useful infor- 
mation on which to base decisions. The importance 
of having a financial system with these characteris- 
tics cannot be overestimated in terms of the value to 
facultv for timely information on grant balances, to 
academic unit administrators for optimizing the use 
of their resources, to managers of self-funded 
enterprises such as bookstores and student housing 
to manage their bottom lines, and to college presi- 
dents who may oversee macro-level allocations, 
budget reductions, and new opportunities across the 
institution. 

Aging. technology. An institution that has used 

the same financial system for the past 20 years will 
likely recognize that technology available today can 
provide capabilities not possible with the aging 
technology employed by its current systems. Given 
dwindling resources and increased competition for 
enrollment, it is becoming very important to be 
more responsive to the marketplace and to have 
systems that enable more efficient and effective 
administration. Thus having the ability to separate 
transaction systems from decision support systems, 
and/or migrate from character-based interfaces to 
intuitive graphical interfaces may well be drivers for 



ranging the financial system. 



High costs. The costs associated with maintain- 
ing legacy systems can be a key motivator to move 
to a new financial system. These costs can include 
the cost of maintaining the hardware of a propri- 
etary mainframe-based system, the cost of maintain- 
ing and enhancing the software of the legacy 
system, the cost of not having a flexible system that 
will enable streamlining of key business processes, 
the cost of not managing cash balances in an 
optimal fashion that maximizes interest income and 
minimizes working capital expense, and even the 
cost of providing electricity to the legacy systems. 

New leadership. While colleges and universities 
are charged with the discovery of new knowledge 
and the dissemination of knowledge, they can also 
be remarkably slow to recognize and correct inad- 
equacies in their information infrastructure. Often 
such a change is prompted by the arrival of a new 
president or chancellor, a new director of informa- 
tion technology, a new accounting officer, or a new 
senior administrative officer. 

Capturing stakeholder input to build a 
business case 

Having support for change from a respected and 
highly placed steering committee is a necessary but 
rarely sufficient condition to effect that change 
successfully. Changing financial systems will have 
an impact on the lives of many stakeholders in the 



Campus Financial Systems for the Future 



ERIC 



existing system, so it is critical that these members 
of the campus community buy into the need for 
change. 

While many of these stakeholders may complain 
about current aging financial systems, the steering 
committee must not mistake such complaints as a 
signal that the case for change has been made or is 
self-evident. This distinction is subtle but important. 
These are the systems people "love to hate," and 
business systems, practices, and infrastructure that 
people love to hate are systems around which 
fundamental elements of organizational culture 
arise. While we all complain about a fiscal closing 
process that occupies three months of every year, the 
process is nonetheless the one we know best, and 
our jobs are defined by such disagreeable systems. 

Thus, developing a sound business case for 
change is an essential and early responsibility of the 
committee that will guide the development and 
implementation efforts, especially through the times 
when doubt surfaces in the face of the reality of 
difficult change. The particulars of the business case 
will vary greatly from one institution to another 
and will embody the highest-level institutional 
objectives and aspirations both in the area of 
financial management and in the specifics of the 
existing financial operating environment. In spite of 
this wide variation, the process of building the 
business case has a number of common elements. 

First, the steering committee should identify in 
specific terms the principal stakeholders of the 
institution's financial system. The essential point 
here is that the financial system is a nearly ubiqui- 
tous manifestation of the institution's business 
architecture and, as such, affects — directly and 
indirectly — surprising numbers of people. In 
addition, the steering committee must recognize 
that die institutional culture is not monolithic; that 
is, various stakeholders are affected differently by 
the financial system. These stakeholders will have 
different views of the existing financial system, 
different needs and aspirations about the future, 
and consequently differing assumptions about the 
need for change and the nature of the needed 
change. 

One methodology for "mapping" the views of 
the college or university community regarding both 
the existing financial system and high-level future 
aspirations is the deployment of interview and focus 
group teams. Typically, organizing for this activity 



will reveal stakeholders such as the following: 

• Trustees 

• President or chancellor 

• Vice presidents or vice chancellors 

• Deans 

• Faculty 

• Academic officers 

• Academic business officers 

• Student services administrators 

• Information technology staff 

• Departmental accounting staff 

• Central accounting office staff 

• Purchasing officers 

• Grants management staff 

• External and internal auditors 

• External stakeholders (e.g., research sponsors, 
vendors, trading partners) 

While most of these stakeholders will have some 
representation on the steering committee, it is a 
good idea to survey or organize focused discussions 
with other individuals from these groups to elicit 
their views about their current and future financial 
management needs. Not surprisingly, this review 
will reveal both common and divergent needs and 
wants. What the steering committee learns about 
universal views and particular views will inform the 
overall financial management vision of the future 
financial environment, will help set early project 
priorities, and will guide the development of an 
institution-wide communication strategy to support 
the project. Table 1 illustrates how the information 
elicited from a few hypothetical stakeholder discus- 
sions can be organized to reveal both common and 
divergent perceptions about the existing financial 
system and the needs or beliefs about future change. 

The focus group and interview approaches can 
be supplemented with easy-to-use surveys of stake- 
holder needs, beliefs, and satisfaction with the 
existing financial system. Information from such 
surveys can also go far toward preparing the ground 
for change, including broad elements of the institu- 
tion in the process of change, and building a 
tangible and compelling case for change (or not!). 

The deployment of processes to elicit the 
differing views of the financial system does not need 
to be analytically rigorous, or expensive. Remember, 
the purposes of this activity are to: (1) prepare the 
ground for change, (2) convey that the process of 
change is intended to be inclusive, (3) uncover high- 
level commonalities and differences of views, and 
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Table 1 : Capturing stakeholder input 



STAKEHOLDER 


VIEW OF PRESENT 


NEEDS FOR FUTURE 


Trustees 


Information is dated 

Financial statements are hard to read 

Budget and expenditures don't reconcile 


Less data, more information 
A "unified" budget across all funds 
Better cost information 


President 


Every information request is ad hoc 
Information is dated 
Can't tell if institution is overspending 
Too many transactions 


Financial analysis tools 
More timely information 
More cost information 


Academic Officers, 
Academic Business 
Officers 


Lack of timely expense information 
Complex and aggravating fiscal 
closing processes 

Difficult to track expenses versus budgets 
Noncompliance with federal terms 
and conditions 

Weak or nonexistent anlytical tools 


More local accountability demands better 
financial analysis tools and work 
Improved compliance monitoring on 
contracts & grants 
Reduction in departmental shadow 
systems 


Chief Technology 
Officer 


Legacy systems expensive to maintain 
Data integrity concerns 
Expensive report generators 
Diverse desktop platforms 
Incomplete network connectivity 
Legacy systems impede progress 
toward new architecture 


User-supportable systems 
Enter data once, use many times 
Customizable online reporting 
Common graphic user interface, seamless 
interoperability 

Robust and ubiquitous campus network 
Scalable and portable applications 


Chief Financial 
Officer 


Information is dated 
Financial performance hard to convey 
Proliferation of shadow systems adds risk 
Decision support needs unmet 
Practices are labor intensive and costly 


Information is accessible 
Reports are comprehensible 
Enter data once, use many times 
Specialized decision support tools as needed 
Electronic approvals and commerce 


Technology Staff 


High-maintenance legacy systems 
Increasing user independence 
Pressures to reduce reliance on mainframe 
Pressure to adopt client/server models 
Batch systems 


Increased system modularity 
Increased integration among systems 
Online systems, reliance on networks 
Graphic interfaces, heterogeneous platforms 
Support for distributed computing 


Faculty 


Lack of timely expense encumbrance 
and balance information on grants 
and contracts 

Confusing written financial reports 
Information not easily accessed from 
multiple platforms 


Timely online information 
Online purchasing 
Checkbook-register ease of use 
Automated controls for compliance with 
different contract terms and conditions 
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(4) supply "back of the envelope"-quality informa- 
tion to help the steering committee members 
understand potential priorities and pockets of 
potential project support or resistance. If resources 
permit, the use of outside facilitators to conduct this 
early discussion will go far in building objectivity 
into future project plans and actions. 

Establishing a Vision 

Involving major stakeholders in making a business 
case for change provides members of the steering 
committee with the information they will need to 
engage in an essential discussion about, and estab- 
lish a vision for, the future of the institution's 
financial operating environment. At this still-early 
stage of the project, the steering committee mem- 
bers must resolve the strategic and fundamental 
question of incrementalism versus dramatic change. 
Based on the feedback of major stakeholders, the 
steering committee must answer three questions: 

• How much in need of change are the existing 
financial processes and systems? 

• How different will the institution's future be 
from its past? 

• What are the key attributes of a new system? 

The resolution of these questions will define much 
of the scope of the project ahead and will also drive 
decisions about the roles and responsibilities that 
people will associate with the project. 

One method of resolving these questions is to 
create a "vision" of the institution's future financial 
environment. The process of creating a vision is one 
in which the steering committee in a concentrated 
period (one to two days) assesses and organizes the 
information collected from the stakeholders and 

Figure 2: 

Integrated vision hierarchy 



makes fundamental planning assumptions about the 
nature of the future academic focus, the envisioned 
institutional "business model," the institutional 
financial model, and the nature of the institution's 
future information and technology architectures. 

The process of establishing a vision is an 
essential one, and one that is both difficult and 
exciting. Setting the context for discussion at some 
realistic time in the future (often five years) usually 
invokes people's creative instincts and reduces some 
of the territorial "politics" of the present day. The 
difficult aspect of this process in the higher educa- 
tion context is the typical lack of explicit institu- 
tion-wide plans or visions for the core academic 
enterprise. Ideally, the development of sound 
financial systems that will serve the institution for a 
decade or more depends on the explicit linkage 
between an academic plan and vision, its envisioned 
business and financial model, and its envisioned 
information technology architecture. The relation- 
ship of elements of such an integrated vision can be 
described as a hierarchy, with the financial system 
and campuswide network forming essential ele- 
ments of the base infrastructure (see Figure 2). 

While the creation of such a vision is a consen- 
sus-building exercise, the nature, decentralized 
structure, and even mission of most colleges and 
universities make it unlikely that senior planners 
will "uncover," in any one place, explicit institution- 
wide academic visions and plans. (It is more likely 
that a future information technology architecture 
has been articulated in a vision or planning docu- 
ment, including strategies for the campus network 
and core systems.) The absence of clear guidance at 
"the top of the pyramid" weakens vision exercises, 
but neither dooms them to failure nor consigns the 
results to the realm of irrelevancy. 

Steering committee members will need to resist 
the temptation to abandon or delay the vision- 
setting exercise owing to the lack of an articu- 
lated institutional vision. Instead, the commit- 
tee should develop a surrogate (and loosely 
defined) vision of the institution's future by 
making some well-informed assumptions 
through discussion with the president or 
chancellor, and with key academic 
opinion leaders. 

Each institution's vision process 
will be different and will yield very 



Academic Vision & Plan 






Business Vision & Model 



Financial Vision & Model 







Future Technology Architecture 



4 



Campus Network & Core Systems ^ 







22 




^PtfeogOaGBopg a 



different results. This processing can be structured 
around answering a number of high-level questions 
in four areas: the academic enterprise, business and 
financial enterprise, cultural and organizational 
environment, and information technology enter- 
prise and architecture. 

Academic enterprise 

■ Student Enrollments 

Are student enrollments increasing or decreasing? 
(This is not simply a matter of revenue; the financial 
systems will need to integrate with the student 
systems.) Where is growth and/or contraction 
occurring? Is your institution attracting more adult 
and part-time students? Is the percentage of students 
on financial aid increasing or decreasing? What are 
the trends in how students pay their bills? Are credit 
or debit cards an element of the envisioned environ- 
ment? Is student revenue rising or falling as a 
percentage of total revenues? 

■ Research Funding 

Is research funding increasing or decreasing? How 
dependent on research funding will the institution 
be in five years? ten years? What is the mix of 
federal, state, and private funds for research? What 
are the regulatory, reporting, and audit requirement 
trends in these areas? 

■ Academic Growth or Retrenchment 

Where is academic growth or retrenchment occur- 
ring? Is your institution committed to a balance of 
the liberal arts, or is the shape of the academy 
"following the funds"? What are your institution's 
academic centers of excellence, and is there a long- 
term commitment to maintaining these historical 
strengths? What are some of the new emerging 
growth disciplines, and what are the financial 
characteristics of these disciplines? Are there plans 
to evaluate the cost effectiveness of program and 
course offerings and the potential related invest- 
ments in instructional technology? 

■ Distance Learning and Extended Education 

Does your institution have a plan in this area? What 
student markets do you wish to reach and to empha- 
size? What are the financial/consumer behaviors of 
students in these markets? The financial system 
serving a "distant learner" will be organized differ- 
ently from one organized for the traditional 18- to 
21 -year-old resident undergraduate. 

O 




Business and financial enterprise 

■ Revision of Existing Chart of Accounts 

Does your institution desire or need to retain its 
chart of accounts? How many "charts" do you need 
for external and internal reporting? The nature of the 
chart of accounts, and how flexible your institution 
can be in this area, will be a determining factor in 
the number and type of financial systems that will 
be options for your institution. 

■ High Tech Versus High Touch — or Both 

Will your institution emphasize high tech, or high 
touch; that is, how important will human interven- 
tion be in the way your institution interacts with 
financial stakeholders such as students, faculty, 
vendors, and others? What kind of management 
system or model will you have? 

■ Business Philosophy and Practices 

How important is speed and flexibility to your 
institution's business success? Does your institution 
"go after" purchasing discounts aggressively? How 
does the age of campus receivables (federal contracts, 
student) affect campus financial performance? What 
place do electronic data interchange and electronic 
commerce have in your institution's future? Are 
there currently numerous "shadow systems" or 
duplicate financial books? How important is stan- 
dardization and elimination of work duplication? 

■ Accountability and Control 

What is your institutional philosophy of internal 
control? What is the envisioned financial control 
system? Are multiple approval signatures an embed- 
ded element of institutional operating practices? 
How important is control over financial commit- 
ments and expenditures, and how current must that 
information be? What is the organizational unit of 
accountability for expenditure control? for revenue 
planning and control? 

■ Business Complexity 

How diverse is your institution's business enterprise, 
and will this enterprise become more, or less, diverse 
over time? How tightly integrated are enterprises like 
medical centers with the financial activity? What 
role do the auxiliary enterprises play and how 
specialized are their needs? 

■ Business Image 

How important is your institution's image as a 
business entity? How does the governing board view 
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the institutional business enterprise? Do outside 
entities (vendors, contractors, research sponsors) like 
doing business with your institution? Does your 
leadership value your institution's business image? 

Cultural and organizational environment 

■ Decision-making Style and Structure 

How are decisions made at your institution and 
what are the financial consequences? Are financial 
decisions and accountabilities delegated to the deans 
and department chairs or to central campus officers? 
How much reliance is placed on financial informa- 
tion to inform decisions? Where is the locus of 
budgetary control? Are operations being recentral- 
ized to control costs, or is your institution moving 
to models like responsibility center management? 

■ Technological Sophistication of the Customer Base 
Are the primary users of the envisioned financial 
system computer literate? Do financial planners and 
analysts, for example, use sophisticated computer- 
based analytical tools? What is the employee 
turnover rate likely to be among various system 
users? What is the institutional commitment to 
training for those who will use the financial system? 

■ Attitudes and Values Regarding Business 
Partnerships 

One strategic decision that nearly every college or 
university planning a new financial system will face 
is whether to purchase vendor solutions or build 
systems in-house or in partnership with other 
institutions and/or vendors. Attitudes, values, and 
skills across the institution will influence this 
decision strongly. Is joint or contractual develop- 
ment and/or operation of the financial system a 
desirable planning option for your institution? Do 
the skills to manage such relationships currently 
exist at your institution, in the financial and/or 
information technology organizations? 

■ Use of Management Information 

How do different institutional financial stakehold- 
ers use financial information? In what form (reports, 
online, raw data) is financial information used? 

What key information is not available? How impor- 
tant is the currency of financial information to 
different stakeholders? Is financial planning and 
analysis an activity widely practiced across the 
institution, or is it localized in the institutional 
budget office or the auxiliaries? 



Information technology enterprise and 
architecture 

■ Institutionwide Computing Directions 
Financial systems that are developed today require 
data connectivity to virtually every office that either 
deals directly with the financial system, or is con- 
nected indirectly via one of many auxiliary or 
peripheral systems that transmit information to the 
financial system. How technically heterogeneous is 
the institutional computing environment? Is a 
campuswide network in place? Is it robust and 
considered important? Are there standards and 
strategies that assure the existence of a basic level of 
workstation capability and network connectivity 
among those who will use the financial system? 

What is the expected level of interdependence 
among institutional systems, such as the general 
ledger, budgeting system, purchasing and A/P 
systems, student systems, and departmental account- 
ing systems? What is the institution's attitude about 
mainframe computing and client/server computing? 
Is there recognition of the need for life-cycle budget- 
ing to support the network infrastructure as a 
utility? If the envisioned business architecture 
assumes widespread electronic commerce, does the 
infrastructure exist for authenticating users of the 
financial systems? 

■ Level of Technical Expertise 

Depending on the characteristics of the new finan- 
cial system, the institution will need varying levels 
of technical support for the planning, development 
or purchase, implementation, and ongoing mainte- 
nance of the new financial system. Are current 
technical staff knowledgeable and skilled in newer 
technologies? The configuration of the new system 
may also dictate the location of such expertise, 
depending on whether it will be on a central main- 
frame or distributed on database servers throughout 
the institution. Do technical support staff reside 
primarily within the administrative computing 
department, within the central functional units 
(e.g., the accounting office, budget office), or at a 
dean's office or academic department level? Does 
the financial office have the technical and manage- 
rial wherewithal to manage large software develop- 
ment and implementation projects? 

In many cases, the vision process can benefit 
from the use of a professional facilitator. Most 
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effective vision activities are supported by a moder- 
ate amount of staff data collection and analysis and, 
as suggested earlier, can be concluded in a brief, one- 
to-two-day retreat. 

The key to success in creating a vision is not 
only to ask the right questions, but also to keep the 
dialogue at a very high level. There will be pressures 
to "dig deep," but this is not the time to do that. 

Keep in mind that the primary objective of the 
vision session is to establish the general shape and 
direction of the project. Teams appointed later in 
the project — to undertake business process evalua- 
tions and a detailed information technology evalua- 
tion-will test the assumptions and beliefs estab- 
lished in the strategic overview stage. 

Having completed the vision exercise, the 
steering committee should develop a simple, concise 
vision statement to serve as the foundation for the 
financial systems project. For example, the Univer- 
sity of California is developing its financial systems 
based in part on the following vision: 

"In the year 2000, most or all of the University's 
internal and external commerce will take place 
electronically. Electronic funds transfers will 
help [the University] pay its employees and 
vendors, while electronic data interchange will 
simplify a host of financial processes (e.g., order 
entry) that link [the University] with our 
customers, trading partners, and regulatory 
agencies. The focus of University financial 
operations will be on the elimination of transac- 
tions that demand cash, checks, invoices, or 
other labor-intensive transactional intermediar- 
ies." 2 

A vision such as this has significant design implica- 
tions and can galvanize interest and support across 
the institution in powerful (good and bad!) ways. 

Establishing Planning Principles 

The effective implementation of such a high-level 
vision depends on the existence of a set of principles 
to guide downstream decisions. An exercise to 
develop such principles for the new system should 
be the next order of business for the steering com- 
mittee. Principles are typically developed in the 



2 Report of the Financial and Accounting Systems Task Force 
(Oakland, Calif.: University of California, 1994), 12. 
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form of declarative statements of design intentions. 
For example, planning principles recently adopted by 
the University of California as part of its process of 
establishing a strategic framework for implementing 
a financial information system include the follow- 
ing: 

• Design for the future 

• Design for effective and efficient internal 

control 

• Leverage existing investments in the financial 

management infrastructure 

• Design for ease of use by the primary 

stakeholders 

(These principles are elaborated in a sidebar on the 
next page; additional examples of planning prin- 
ciples from other institutions are included in 
Appendix A.) 

When partnerships with external vendors or 
other institutions are anticipated, the steering 
committee will need to develop principles that 
define desired partner behaviors and parameters, as 
well as expected partnership outcomes. 

Principles, like vision statements, have the 
potential to create powerful consensus and good will 
for the project. They often appear to be simplistic or 
superficial in nature. While this can be the case, it 
rarely is. Principle statements that are developed in 
an atmosphere of commitment, trust, and mutual 
respect are often compellingly simple, rather than 
simplistic. The process of establishing these funda- 
mental statements often creates the glue that holds 
projects of this kind together for a successful 
conclusion. Most important, these principles form 
much of the yardstick against which elements of the 
future system are judged and against which design 
decisions can be evaluated. 

The vision and principles of the steering com- 
mittee form, in essence, a touchstone for the project. 
They also define — with project budget and schedul- 
ing performance — the basis on which key project 
milestones and outcomes can be evaluated. 
Throughout the project and especially during major 
milestone reviews, project design and implementa- 
tion decisions should be reconciled to the stated 
vision and principles. On an informal and ongoing 
basis, steering committee members must always ask 
how a recommendation or choice will move the 
project closer to realizing the stated vision. 

During formal reviews of project milestones, 
elements of the vision and principles can and should 
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✓U Design for the Futures 



An institution's finandal operations and informa- 
tion architecture should be designed for the future,. and 
should exemplify theigoals of simplification, localiza- 
tion of decision-making/ customer service, .innovation, 
and evaluation of outcomes. 



✓o Design for Effective and Efficient Internal 

Control - . 

Internal control is broadly defined as "a process, ef- 
fected by an entity's Board of Directors, management and 
other personnel, designed to provide reasonable assur- 
ance regarding the achievement of objectives in the fol- 
lowing categories: (1) effectiveness and efficiency of op- 
erations; (2) compliance with applicable laws and regula- 
tions, and (3) reliability of financial reporting." 3 While 
an institution's underlying control objectives may not 
change, there is a significant change in how colleges and 
universities are implementing such controls. To enhance 
the flexibility, agility, and service orientation of adminis- 
trative operations and to leverage the full capacities of 
employees and new technologies, "management should 
no longer attempt to control processes but must focus on 
controlling exposure to risk." 4 



/ Leverage Existing Investments in the 

Financial Management Infrastructure 

As an institution's operating and technology envi- 
ronments become increasingly complex and as adminis- 
trative resources become more scarce, investments to sup- 
port financial management must be leveraged to the great- 
est extent possible. Through the 1980s, when mainframe- 
based transaction processing investment provided the in- 
frastructure for many campus financial systems, leverage 
was a function either of scale or of commonality. No in- 
stitution can afford to simply throw out the investment 
in personal computers, networks, and many other sub- 
sidiary and auxiliary systems; it must decide what it can 
keep and what it must discard. 



— / Design for Ease of Use by the Primary 
Stakeholders 

Campus users' expectations for financial systems have 
gone beyond unfriendly terminal emulation screens and 
unreadable reports and ledgers. Primary stakeholders will 
expect the new campus financial system to be easy to use 
and intuitive in its "look and feel, "to integrate well with 
other application programs on their desktop, and to re- 
quire minimal training. Stakeholders also know that 
today's technology allows for these characteristics, and 
therefore will not accept a system that doesn't offer sig- 
nificant improvements over their current system.. 





be translated into formal measures to help assess the 
outcomes of the project. If, for example, there is a 
vision of robust electronic commerce, the percent- 
age of payroll, purchasing, and other transactions 
performed electronically can be measured. Some of 
these measures should be devised early in project 
planning, for even successfully implemented 
projects can fail in the minds of some campus 
constituents for lack of effective communication of 
project success in measurable terms. 

Evaluating Readiness for Change 

At this stage of the planning process, steering 
committee members will have developed a high- 
level, shared vision of the target campus business 
model, agreement on basic assumptions about the 
financial system to support this model, and a set of 
planning principles that will guide the project. The 
next steps will be to assess more closely the poten- 
tial barriers to change, and then to validate the 
vision and principles by communicating them to the 
campus community and eliciting feedback. 

Identifying potential barriers to change 

While the strategic planning process for the 
systems project has been enriched by informed 
discussion, it probably has not yet taken sufficient 
account of the barriers likely to emerge in moving 
from a strategic discussion to a live project. 

The primary barrier to initiating a project of this 
magnitude is the lack of executive management 
support. While executive management should be 
well represented on the steering committee, mem- 
bers of the committee must not assume that other 
institutional leaders either understand or share the 
conclusions of the planning process. At Wellesley 
College, for example, although senior management 
was involved throughout the planning process, the 
full understanding of what such a project would 
involve did not crystallize until the actual imple- 
mentation was under way. Failure to achieve the 
fully knowledgeable buy-in and support of executive 
leadership can put the project at risk downstream 



3 L. Hubbell and ). Dougherty, Cost Effective Control Sys- 
tems for Colleges and Universities: A New Paradigm (Washing- 
ton, D.C.: NACUBO, 1992). 

4 Higher Education Management Newsletter (Coopers & 
Lybrand, August 1993), 13. 
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when the inevitable challenges will occur and finan- 
cial commitment can waiver. 

Another major and often overlooked barrier to 
change is the institutional culture. If the steering 
committee's vision of the future includes the elimi- 
nation of paper-intensive approval processes, the 
adoption of new credit and debit cards, and substan- 
tial reliance on business partnerships, while the 
current practices at the institution are labor- and 
paper-intensive and highly centralized, there is a 
high risk of employee resistance to the planned 
changes. Again, the current financial operating 
environment — and its systems — may be universally 
hated, but social psychologists warn us that people 
will often show a preference for the devil they know 
than for future uncertainty. 

In the past few years, a number of institutions — 
for example, the University of Michigan, University 
of California, and Pennsylvania State University — 
have worked with consulting organizations to devise 
survey tools to assess cultural resistance to change on 
their campuses. The deployment of these tools can be 
a cost-effective way to assure those affected by the 
potential change that their concerns are being 
accounted for in the project planning. These tools 
can also go far in highlighting where attitudinal, 
training, and other gaps are likely to be found 
throughout the institution and where management 
attention can be focused throughout the project. 

A third major barrier to change is the state of the 
institution's existing information technology 
infrastructure. This area, which depends on the 
institution's historical investments in and approach 
to information technology management, is often one 
that can be a showstopper. For example, if the institu- 
tional vision is to decentralize online financial 
transactions to academic departments, the state of 
both the workstation environment and the local and 
campuswide network connectivity will either enable 
or hinder progress toward achieving the vision. The 
lack of modern computers or a robust and wide- 
spread campus network can force project planners to 
conclude: "We can't get there from here." 

Validating the vision and principles 

At this stage, members of the steering committee 
must become champions of the vision and principles 
they have created and must begin to bring their peers 
and organizations into this vision. Foremost, the 
preliminary statements of the steering committee 
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must be discussed among members of the 
president's or chancellor's cabinet, the council of 
deans, and among the leadership of the academic 
senate. These discussions should conclude with 
either a clear direction to move ahead or clear 
course corrections. 

It may also be wise to hold campuswide forums 
to draw comments and suggestions on the vision 
and principles for the new system and how the new 
system will interrelate with other systems. This 
broadening activity can be accomplished in a 
number of ways. No matter what approach is taken, 
it is essential for the steering committee to commu- 
nicate their leanings and enthusiasm in ways that (1) 
elicit honest feedback, (2) ignite enthusiasm for 
moving ahead, and (3) manage expectations of the 
campus community. 

AffticiflUMiiug Goals and Strategies 

Having evaluated readiness for change, the steering 
committee is ready to establish goals and strategies 
to guide the project teams and investments. One 
methodology for framing the development of such 
goals and strategies is conducting a gap analysis. 

In essence, the steering committee at this stage 
must understand how much change this project will 
introduce to the institution in order to set priorities 
and develop programs that will mitigate the poten- 
tially negative effects of the change. The failure to 
assess realistically the gap between the desired 
"future state" and the "current state" will result in 
overlooking important areas of risk and needed 
investment. 

Conducting a gap analysis 

A gap analysis is neither difficult nor expensive. 
It can be as simple as the illustration provided in 
Table 2. This example is clearly polarized to high- 
light areas where extreme differences between the 
current and future environments can occur. Each of 
the gaps defined in this process can be narrowed 
through the development and deployment of 
different project goals and strategies. 

Developing the gap analysis, then setting goals 
and developing strategies to reduce the likely gaps, 
will help the project sponsors and other members of 
the steering committee develop realistic priorities 
and assess the realistic resource requirements 
associated with this project. 
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Assessing resource requirements to 
close the gap 

Once the gap analysis has been performed, it is 
important to attach resource requirements to the 
elements identified in the analysis — that is, the 
areas of needed investment that fall between where 
the institution is and where it wants to be — to 
ensure realistic goals and strategies. Resource 
requirements include, but are not limited to, the 
following components: 

One-time development costs. One-time costs may 
include software acquisition or development, 
hardware procurement or upgrade, training of 
system users and administrators, the opportunity 
costs of staff dedicated to system design and imple- 
mentation, the hiring costs of any outside consult- 
ants for development, and other specific project 
costs. 

Skill development. In addition to the initial 
training required for users and systems administra- 
tors, there will be an ongoing need for training of 
users of the financial system. These costs can be 
managed to a large extent depending on the charac- 
teristics of the system solution that is selected. For 
example, a financial system that has hundreds of 
screens that must be navigated, in which each screen 



Table 2: Cap analysis 



has many codes, will require much more ongoing 
training investment than a system that has a mini- 
mal number of screens and reports, with each screen 
and report organized intuitively, and which includes 
context-sensitive, online help facilities and integrates 
well with applications that are already in use at the 
institution. 

Computing infrastructure. The new system will 
possess different performance attributes and will 
generate new patterns of use at the institution. 

These changes will consume different amounts of 
the institution-wide computing infrastructure. 
Planners of new financial information systems will 
need to forecast those incremental infrastructure 
consumption costs early in the planning process. 

Other ongoing expenses. Other miscellaneous 
costs include those associated with post-implementa- 
tion maintenance (who and how), replacement of 
hardware downstream, future development ex- 
penses, and so forth. 

A key concept associated with assessing resource 
requirements is that of life-cycle costing. Too often, 
project planners focus attention on a variety of one- 
time costs, such as hardware and software acquisi- 
tion, training, and the like. Experience shows that 
these costs, while significant, are often the smaller 



CURRENT STATE 

The Cultural Environment 

Centralized decision-making 
Information closely held 
Resistant to change 
Organizational territoriality 

The Business Environment 

Multiple transaction approvals 
Central office driven 
Paper intensive 
Information scarcity 
Focus on controls 
Labor intensive 

The Technical Environment 
Mainframe based 
Homegrown software 
Batch processing 
Technical homogeneity 
Stand-alone systems 



FUTURE STATE 




The Cultural Environment 

Distributed decision-making 
Distributed information 
Embraces change 
Collaboration ' 

The Business Environment 

Online transaction approvals 
Distributed authority 
Reduced paper 
Distributed information 
Focus on service quality 
Automated wherever possible 

The Technical Environment 
Client/server based 
Vendor-developed software 
Online transaction processing 
Technical heterogeneity 
Integrated systems 
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Table 3: Tying goals and strategies to planning principles 



GOALS 



STRATEGIES 



Planning Principle #1: Design for the future 

Localize financial accountability / Departmental online access to campus transaction systems 

/ Departmental^ accessible decision support system 
/ Online transaction processing 



Planning Principle #2: Design for ease of use 



Reduce training time and effort 

Integrate systems to interact 
seamlessly across campus functions 



/ Graphical user interface and sophisticated online help 
/ User-friendly reporting templates and natural query languages 
/ Common user interface and data dictionary across applications 
/ Data warehouse with single interface 
/ Software "hooks" across applications 
/ Mapped process and information flows 



Planning Principle #3; Design 

Reduce the number of "shadow 
systems" 



Improve campus financial 
management 



for efficient , effective internal controls 

•/ Separate transaction processing from analytical processing 
/ Implement easy access to local (e.g., departmental or individual) 
information 

/ Assure the timeliness and quality of financial data in campus systems 
/ Embed process controls in systems to streamline approvals 
/ Provide secure, clear, and easy-to-understand audit trails in 
transaction processing systems 



elements of total project costs when they are viewed 
in light of the useful life of the technology being 
considered. Hardware and software depreciation, 
network upgrade management expenses, software 
maintenance, and a variety of recurring expenses 
must be accounted for in the communication of 
project resource requirements. The failure to look at 
costs on a life-cycle basis can put projects at risk by 
understating true costs. 

The steering committee is charged with oversee- 
ing institutional investments in this project, but is 
not typically responsible for the detailed costing of 
planning alternatives that are to be evaluated. Its 
role at this stage of the project is to identify the 
various cost categories that are likely to characterize 
projects of this kind and to help identify where large 
categories of cost are likely to fall. If training costs 
are likely to be felt strongly by deans and depart- 
ment heads, then either strategies must be developed 
to finance these costs, or advance warning must be 
issued to ensure that downstream funding surprises 
do not erode institutional support for the project. 

Goals and strategies should relate strongly to the 
vision and principles developed by the steering 
O 




committee in the earlier stages of the planning 
process. Table 3 provides an example of how goals 
and strategies can be linked to the principles that 
have been established. 

Developing a Decision Framework 

If successful, the steering committee's planning 
process will navigate the institutional leadership 
through a great many of the key scoping decisions of 
the project. These scoping and priority decisions 
define early in the project the potential "wins" and 
"losses" associated with the inevitable tradeoffs that 
will occur in any major systems endeavor 

Understanding the tradeoffs 

In this strategic phase of the project, the steering 
committee will need to weigh potential tradeoffs in 
a number of areas. Such discussions should result in 
strategic recommendations that will help to guide 
the work of the project management team. 

Incremental change versus fundamental change. 
The steering committee should address whether or 
not the replacement of the core institutional finan- 
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cial system should open the door for a significant 
review of institutional financial practices. For 
example ; a stated goal of being a "close follower" in 
technology, coupled with a goal of centralizing 
financial management responsibilities at your 
institution and a stated principle of maximizing the 
utilization of the campus mainframe computer, may 
suggest an incremental improvement strategy. A 
leadership decision to implement responsibility 
center management, on the other hand, suggests the 
need for significant new technical solutions. 

Host-based versus client/server architecture. A 
presumption of this book is that your institution 
has articulated an information technology strategy 
that addresses whether administrative systems will 
continue to be mainframe-based. It is essential that 
the steering committee understand that strategy and 
incorporate thinking about the financial informa- 
tion systems into the context of the planned institu- 
tion-wide technology architecture. 

This is a difficult but essential activity. It is 
difficult because the range of technology alterna- 
tives available to colleges and universities is greater 
than ever and because the life cycles of these alterna- 
tives are becoming more and more difficult to plan 
for and manage. 

At many large research universities, architec- 
tures that distribute data handling responsibilities 
and those that operate in graphical user environ- 
ments are preferred increasingly to traditional 
mainframe applications. These architectures are 
needed to support the decentralized environments 
of these institutions and to facilitate organizational 
efforts to localize decision-making. 

Two factors that should be included in any such 
tradeoff discussions are that (1) currently there are 
not as many commercial client/server solutions 
available as host-based products, and (2) it can be 
difficult to integrate client/server solutions with pre- 
existing mainframe systems. Client/server solutions 
also assume that substantial investments have 
already been made in the campus telecommunica- 
tions infrastructure and a contemporary end-user 
desktop computing environment. Client/server 
architectures can be riskier to develop and maintain, 
can be costlier, and will distribute a number of 
support and maintenance costs to the end user. 
Recalling, however, that financial systems usually 
have long lives, the real risk may be in failing to 
consider such solutions. 



In general, financial systems should not be the 
driver of infrastructure investments. As with all 
tradeoff decisions, each college and university will 
have to strike its own unique balance of risk, future 
orientation, user satisfaction, and cost. The market- 
place is changing rapidly, with new vendors emerg- 
ing on the scene with client/server products and 
vendors with more traditional host-based solutions 
beginning to develop or deploy client/server solu- 
tions. In this volatile marketplace, one strategy some 
institutions are employing is to take a "hedge" 
position by acquiring only those client/server system 
components that are most mature and deferring a 
major portion of the system replacement until the 
technology is more proven. 

Finally, many institutions are beginning to 
consider using the World Wide Web as an interface 
to data in secured administrative databases. The Web 
reduces or eliminates many of the complexities 
associated with distributing information and ana- 
lytical functionality to different hardware and 
software platforms and, therefore, is likely to play an 
important role in the emerging institution-wide 
information technology architecture. Some tech- 
nologists are beginning to predict that emerging 
Web-based tools will facilitate development of 
applications to the extent that the future will be one 
of "network-centric," rather than "desktop-centric," 
architectures. 5 The steering committee should seek 
to understand and convey the potential role to be 
played by the World Wide Web in administrative 
applications in the future. 

Transaction processing versus decision support. 
Another tradeoff consideration the steering commit- 
tee may deal with is in the area of creation, manage- 
ment, and use of financial information versus the 
processing of financial transactions. In many cases, 
the chief driver of change is the lack of timely, 
reliable, and/or comprehensible information for 
governing board members and institutional deci- 
sion-makers, rather than failing transaction process- 
ing systems. While on occasion such a problem 
necessitates the renewal of the institutional chart of 
accounts and ledger, in other cases the problem can 
be addressed more easily and cost effectively 



5 Jim Flynn and Bill Clarke, "How JAVA Makes Network- 
centric Computing Real," Datamation , 1 March 1996 (avail- 
able on the World Wide Web at http://www.datamation.com/ 
Plugln/issues/1996/marchl /03ajava6.html). 
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through creating a data warehouse and deploying 
online analytical processing (OLAP) tools. 

This steering committee recommendation has 
"significant implications — financial and otherwise — 
for the project and can be framed as an "either-or" 
decision, or as a phasing decision. Many colleges 
and universities have met their decision-support 
requirements through these approaches at relatively 
low costs, earning valuable credibility and time for 
the more costly and complex replacement of the 
underlying transaction-processing systems. A 
decision to place priority effort on solving the 
problem of information access and presentation also 
allows time for marketplace solutions using newer 
technologies to mature and gain acceptance. 

Best-of-class versus integrated solution. Another 
tradeoff decision is whether to seek the best solution 
for the financial system as a stand-alone application 
or to seek a solution that is part of an integrated set 
of systems. As mentioned earlier, while integrated 
systems can reduce training expenses and improve 
system outputs from the end users' viewpoint, the 
higher the degree of application integration, the 
lower the flexibility of any single component. 

This tradeoff need not be made within the 
context of total application integration versus no 
integration. There are many stakeholders for the 
financial system and there may be a significant focus 
on business process reengineering, so some level of 
integration with other stakeholder systems may be 
inevitable. The design of the application interfaces 
to achieve integration, particularly of database 
information, may be an alternative to total applica- 
tion integration. 

The decision about the degree of desired inte- 
gration between elements of the financial system 
and other information systems will have a signifi- 
cant impact on the scope and nature of the project. 
For example, an institution that is seeking a high 
degree of integration, but has a low-to-moderate 
tolerance for taking risks, is likely to seek a solution 
of purchasing mature, off-the-shelf product suites. 
Such solutions may have shorter useful lives, unless 
the vendor is committed to migrating its products to 
emerging technological tools and environments. 

Signature control versus post-audit accountability. 
The steering committee's principles and vision 
should strive to capture the institution's existing 
and emerging philosophy of internal control. Many 
older financial systems are built around internal 
O 




control procedures that assume the existence of 
forms that must be signed and countersigned. These 
forms and signatures were designed to prevent 
unauthorized transactions from occurring at the 
source, but degrade general performance, since 100 
percent of the controlled activities are regulated to 
prevent those few transactions that may be in error. 

Many institutions are working toward eliminat- 
ing forms-based/signature-based transaction controls 
in favor of new analytical tools for reviewing 
transaction quality on a statistical basis, after the 
fact. This approach improves the speed and user 
satisfaction of financial transactions, but may pose 
higher risks of errant transactions. Again, each 
institution will apply a unique set of values and 
priorities in weighing the tradeoffs between risk 
management, localization of authority, cost, and 
service quality. 

Understanding the build-buy-partner options 

One of the final tasks for the steering committee 
is establishing a general framework that will help 
the institution formulate a strategy for acquiring a 
new financial system, that is, whether the institu- 
tion should buy an off-the-shelf vendor product, 
build or migrate systems in-house, or partner to 
build a new system with a vendor and/or institu- 
tional partners. 

As part of this activity, the committee or an ad 
hoc subcommittee will want to do a quick scan of 
the commercial marketplace as well as "best prac- 
tices" at peer institutions to identify viable solu- 
tions that could be evaluated in more depth later. 

(A note of caution here: the steering committee or 
subcommittee undertaking these external scans 
must be careful not to investigate these potential 
solutions to the extent of product demonstrations or 
campus visits; not only is the level of detail inappro- 
priate in this strategic planning phase, it also opens 
the door to committing to a solution before require- 
ments have been fully articulated by later project 
teams.) 

The steering committee cannot, at this early 
juncture, make a final decision regarding whether 
the institution should buy, develop, or partner to 
develop a financial system solution. The committee 
can, however, simplify the downstream analysis and 
decision-making by providing an overall strategic 
direction in this regard to guide the work of the 
project teams and to be validated or revisited later in 
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the selection process after business processes and 
the technology environment have been evaluated, 
requirements have been articulated, and potential 
external solutions have been carefully investigated. 

At the steering committee level, the build-buy- 
partner decision is a function of: (1) the 
institution's culture, (2) initial scope (incremental- 
ism versus fundamental change), (3) technical 
capabilities, and (4) project resources. 

In many ways the cultural decision driver is the 
key one. Many institutions have a tradition of 
maintaining highly integrated, vendor-developed 
packages and have well-founded fears of developing 
core institutional applications on their own. Simi- 
larly, many institutions believe that their size, 
complexity, and uniqueness preclude the implemen- 
tation of an off-the-shelf solution. These institutions 
often have large technology development organiza- 
tions and take pride in a "built-here"culture. 

Another important aspect of culture is the set of 
values and norms surrounding teamwork at the 
institution, the prevailing attitudes about vendors, 
and what might be called the "culture of deadlines." 
The management of strategic partnerships is not a 
trivial undertaking and the steering committee 
should evaluate the campus readiness to engage in 
significant partnership activity, including identify- 
ing the barriers to creating successful partnerships 
with industry and/or with other institutions. 

The decision to engage in business process 
redesign also will affect the build-buy-partner 
decision. A mandate from the steering committee to 
engage in a major rethinking of core financial 
practices should be accompanied by the realistic 
expectation that it may take an in-house develop- 
ment or partnership with a vendor to build a system 
that can support uniquely redesigned business 
processes. Similarly, a decision to encourage funda- 
mental change in combination with a strong bias for 
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an off-the-shelf solution must be accompanied by a 
realistic understanding that with such an approach, 
the change in business processes will necessarily be 
driven by the commercial solution. For some 
institutions, adopting the business process changes 
mandated by a commercial process may enable a 
rapid leap forward in functionality, even though that 
functionality has not been designated by an institu- 
tional process reengineering effort. In either case, it 
will be important for the steering committee to 
communicate the chosen strategy to help manage 
project expectations. 

One strategic model, developed by UC Berkeley 
economist Oliver Williamson (see Table 4), looks at 
two primary variables: the specificity of the product 
or solution sought and the frequency of its use. 6 
Using guidance such as this, an institution that is 
willing to adjust its operations to fit an existing 
software solution might be advised to use the 
commercial market in this way. If the system re- 
quirements are highly unusual, the institution 
might be advised to build a custom solution. Where 
moderate customization is sought but tradeoffs are 
possible, joint ventures or other contractual arrange- 
ments may make sense. 

Another approach to the strategic view of the 
build-buy-partner assessment includes charting the 
institution's complexity along the dimensions of 
size and diversity (which will influence how com- 
plex the system needs are), as well as along the 
dimensions of the availability of and willingness to 
commit human, technological, and financial re- 
sources. For example: 

A small, single-campus institution with a tightly 
focused mission (e.g., religious or vocational educa- 
tion), relatively few administrative stakeholders, and 
few if any resources for internal development may 
accommodate a more centralized financial systems 
approach that would make it possible and probably 
desirable to consider the selection of packaged 
software with little customization. 

A large public research university with multiple 
internal and external layers of accountability and a 
heterogeneous technical installed base of computers 
may require localized and distributed solutions that 



6 Oliver Williamson, "Transaction Cost Economics: The 
Governance of Contractu ra I Relations," Journal of Law and 
Economics 22 (1979): 233-261 . 
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do not yet exist, without substantial customization, 
in today's marketplace; such institutions may well 
have the resources to consider building systems in- 
house or with external partners to achieve their 
special needs. 

Another critical factor — raised earlier in the 
steering committee's evaluations — that will bear 
heavily on the acquisition strategy is how urgent the 
need is for the new system(s) and thus how quickly 
the solution needs to be and can be implemented. 

Most institutions today would agree that a buy 
option is a very desirable outcome, both initially 
and over time — provided that the product meets the 
functional needs at an acceptable level and cost. The 
advantages of a supported product or having other 
institutions using the same product as yours, with 
the attendant user-group leverage on a vendor, are 
compelling. However, it is also clear that this option 
is not always workable for an institution, so the 
other choices need to be explored as well. 

At this point in their process, the steering 
committee can probably make a good estimation as 
to whether resources, time constraints, and other 
factors preclude in-house development or entering 
into an intensive external development partnership. 
In this case, such a strategy must be stated at the 
very outset of the project, to avoid raising expecta- 
tions that all needs identified in the requirements 
definition phase will necessarily be met through an 
existing vendor product. 

Communicating Directions: 

The Steering Committee's Report 

The communication of project directions and 
findings is a complex activity that demands the 
participation of all those involved in the project. 
""There are no clear guidelines that determine who in 
the project should handle what project communica- 
tions. In general, the steering committee is most 
effectively used in situations where high-level 
organizational placement is most advantageous; 
steering committee members should expect to 
handle communications that address high-level 
political concerns, while issues of technical com- 
plexity and business requirements are more appro- 
priately communicated by follow-on project teams. 

Large, complex institutions might find that the 
amount of effort needed to communicate findings 
and directions to campus constituents requires the 
O 



formation of a steering committee communications 
subcommittee. As shown in Figure 1, this subcom- 
mittee ideally would receive direction from both the 
steering committee and the project management 
team. Membership of this group might include 
representatives from the campus communications/ 
public relations office, academic business officers, 
information technology department, accounting 
office, project management team, and steering 
committee. While the steering committee will be 
involved in communicating directly with campus 
decision-makers, this subcommittee might map out 
a detailed communications plan and timetable that 
is geared to all customers and stakeholders. 

The planning process that the steering commit- 
tee members have gone through, when successful, 
serves to create an important level of congruence of 
views among its members. It is a mistake to assume 
that this commonality of thinking and viewpoint is 
widely understood or shared at the institution. Thus 
the steering committee's findings and recommended 
directions should be summarized in the form of a 
written report to the senior executive committee or 
president's cabinet, as well as for broad distribution 
across the institution. 

The length and style of such a report will vary 
according to the taste of the project leaders and to 
the dictates of the prevailing institutional culture. 
The effectiveness of this report — and the associated 
institution-wide communication effort — depends 
on: (1) making the report as readable and intellectu- 
ally accessible as possible, (2) providing the context 
for policy alternatives selected and actions recom- 
mended, and (3) clarifying the tradeoffs that are 
suggested or implied in the steering committee's 
recommendat ions . 

The steering committee's report will set the tone 
for the project ahead, will establish the case for 
action, and will provide the initial scoping bound- 
aries for the project and system. The roles to be 
played by this report and by the supporting commu- 
nications efforts will be essential to the establish- 
ment of broad support for the project and for 
managing initial expectations about the functional- 
ity expected from the new business processes, 
systems, and capabilities. 

Elements of the steering committee report 
should include the following: 

Membership Roster: a listing of the steering 
committee's membership, to signal the breadth and 
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nature of institution-wide involvement in and 
support for the planning process and the project. 

Executive Summary: a summary of the 
committee's charge, key findings, and primary 
recommendations. 

Context : the committee's primary observations 
about the major influences that will drive both the 
need for change and the specific goals, strategies, 
and priorities that are made later in the report. 
Contextual drivers of change can include changes in 
academic priorities, funding shifts, control weak- 
nesses, new institutional leadership, technological 
opportunities, new reporting requirements, and/or 
others. The state of the existing financial informa- 
tion system can be described here, as well. 

Vision Statement : a clear, compelling, and 
succinct statement of vision that frames the priori- 



ties of the upcoming effort in a way that any reader 
will understand. Wherever possible, the vision 
statement should strive to create enthusiasm, while 
avoiding ambiguous concepts and jargon. 

Statement of Principles and Goals : a summary of 
the principles and goals that are expected to guide 
the decisions, choices, investments, and priorities of 
both the project and the financial and information 
technology environments. As with the vision 
statement, the principles must be clear, precise, and 
free from jargon. Meaningful and clear design 
principles and goals provide the basis for down- 
stream project architects and decision-makers to 
evaluate decisions and project outcomes and guide 
fundamental scoping issues in the project. For 
example, a principle regarding the "openness” of 
financial information will influence the range of 




Figure 3: Process flow chart for planning phase 
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Critical Success Factors: ^ 

A? Engaging key stakeholders in leadership 
roles . 

A: Capturing stakeholder input campuswide 
A P Developing a sound business case for 
change to ensure buy-in 
/• Assessing realistically the cultural 
readiness forxhange 

A Articulating current financial model and. 

envisioning future model 
A Communicating effectively the vision, 
strategies, and goals to set expectations 
A Assessing realistically the resources that 
will be required . 

✓ Assessing realistically the gaps that will 
need to be overcome 



ljmd_Mines:r~ . -fr 

AT Funding not dearly committed 

A- Lack of executive support or understanding 



AT Assuming buy-in because of 4:.: : 

dissatisfaction with status quo 
A" Underestimating resistance to change 
A Getting into too much detail in the- 
strategic overview phase 
A- Abandoning academic vision exercise 
because of a lack of an academic plan : 
A- Establishing a vision that exceeds the : 

. , ability of the: institution to achieve it 
A Failing to include life-cycle costs in the. 



resources assessment - 

A Establishing unrealistic timelines and cost 



estimates 



security alternatives explored in the project. Deci- 
sions about the build-buy-partner continuum may 
also be established as a matter of principle, or may 
be stated in the final recommendations section. 

Readiness for Change: a summary of the results of 
the steering committee's assessment of technical, 
operational, cultural, and other barriers to achieving 
the vision. The assessment of barriers, wherever 
possible, should be supported by survey results, 
summaries of focus group meetings, and other 
tangible efforts, since reducing or eliminating such 
barriers will often drive many of the less obvious 
costs of the projects. For example, a decision to 
distribute an electronic supply catalog to support 
-online purchases assumes at least: (1) a robust 
network, (2) a contemporary desktop computing 
environment, and (3) a commitment to either 
institution-wide training or the creation of intuitive 
systems with state-of-the-art help features. 

This section of the report can bring together the 
information about the hopes and expectations of 
different members of the campus community, the 
state of the existing environment, a statement of 
project priorities, and a size-of-the-ballpark estimate 
of the costs of closing the gap between the "as is" 
and the "to be" environments. 

Tradeoffs: a summary of the tradeoffs that have 
h““n considered with a description of the process by 




which the decision framework was established. 
Colleges and universities are organizations in which 
nearly all citizens have a right to vote whether or 
not they hold a stake in the election. In other words, 
the. report of the steering committee, in general, 
needs to convey not only the worthiness of the 
committee's conclusions concerning potential 
tradeoffs, but the rigor of its underlying analysis. 

Recommendations: a summary of key recom- 
mendations or strategies that the steering committee 
has decided to put forth. These recommendations, 
wherever possible, should be clear and concise, and 
should specify to whom the recommendation is 
made, and by when a recommended decision or 
action should be made or taken. 

To prepare the ground for project funding 
approval, leadership support, and broader institu- 
tion-wide participation in the project ahead, key 
members of the steering committee should distrib- 
ute the report broadly and should plan a question 
and answer session open to all members of the 
campus community to introduce the steering 
committee's thinking and to refine that thinking 
further. The completion of the report and subse- 
quent communication activity is a key milestone 
and marks the end of the first phase of the project. 



27 





Chapter III 
Overview 



♦= Appointing the Project Management Team 
Using Partnerships to Achieve Buy-In 
Determining the Scope of the Project 
♦- Establishing a Project Plan 

Employing Good Management Strategies 



"... the costs of introducing new 
technologies to support the old way 
of doing business — 'paving 
cowpaths * — can be both the 
inflexibility of the resulting system 
and the suboptimization of the 
resulting processes." 




Structuring and Managing the Project 



III: Structuring and Managing 
the Project 



ssuming that the business case for 
action and the recommended directions 
for the project have been approved by 
campus executives, the steering com- 
mittee must next appoint a project manager and 
project management team. The role of these indi- 
viduals is to: 

structure and manage the project; 

♦* develop project budgets, schedules, and key 
milestones; 

oversee the business needs identification 
process; 

oversee the technology evaluation process; 
develop a requirements document and seek a 
solution; 

recommend a financial systems solution that 
will be congruent with both the campus vision 
and the articulated requirements; and 
oversee the acquisition and implementation of 
the solution. 

Appointing the Project Management 
Team 

Financial systems projects can be managed success- 
fully from nearly any organizational platform — 
information technology, administration, finance, 
-budget. What isxritical is that the project manager 
be an individual who has the confidence and respect 
of the leadership of these organizations, credibility 
within the institution, strong people skills, and the 
ability to navigate, integrate, and communicate the 
broad interests of the campus stakeholders in the 
planned system. In the ideal situation, the project 
manager will emerge from the ranks of the steering 
committee members so as to ensure continuity of 
thought between the early steering group planning 
activities and the downstream work of the project 
management team. If this cannot be the case, the 
project manager must be made an ex-officio mem- 

O 
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ber of the steering committee once he or she has 
been named. 

In addition to a variety of technical and/or 
application/functional skills, communication 
ability, and project management skills and experi- 
ence, the project manager must possess the judg- 
ment and political acumen to understand the key 
turning points of the project and to invoke the aid 
of the steering committee and various project teams 
at appropriate times. 

In general, the project manager will rely on the 
steering committee to gamer resource support and 
to retain the support of the institutional leadership 
for the project. Similarly, this manager will need to 
work with a project management team to formulate, 
ratify, communicate, and support important deci- 
sions of a primarily business process and technical 
nature throughout the course of the project. In 
general, the steering committee most effectively will 
act in situations where there are high-level political 
concerns, while issues related to technical and 
business requirements will be more appropriately 
evaluated by the project management team (see 
Table 5). 

The project management team will have overall 
responsibility for the success of the financial systems 
project, from planning through implementation. 
Thus, members of this team should be selected for 
their interest in and commitment to the goals of the 
project and should represent a broad cross-section of 
the campus community. Whenever possible, mem- 
bers of this team should include individuals whose 
opinions are frequently consulted at the institution, 
whether or not such individuals are known to be 
supporters of the central financial or technology 
offices. 

The collective credibility of the members of the 
project management team will have a considerable 
influence on the project's eventual outcome. 
Particularly in smaller organizations, it is likely that 
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Table 5: A model for guiding intervention and communication 
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the members of the project management team will 
also be involved in the implementation process. 
Indeed, the same group of people may make up the 
core of several different functional teams, such as 
the project management, some of the business 
process review teams, the technology evaluation 
team, and the implementation teams. Note that all 
of these teams do not necessarily need to be created 
as separate entities, but all of the functions ascribed 
to the teams suggested must be achieved in order to 
have a successful project. (Figure 1 on page 11 
provides an overall view of project roles and struc- 
ture, while Table 6 on the opposite page lists the 
functions of the suggested teams.) 

The effectiveness of the project management 
team will be the decisive factor in the success of the 
project, and thus the roles and responsibilities of 
this group must be made clear from the start. 
Everyone who is engaged on the project manage- 
. mentteam must be a contributing member who is 
able to bring his or her own departmental expertise 
and allegiances to the table, while also being able to 
integrate those needs with the larger institutional 
vision spelled out by the steering committee. Team 
members must be given enough time away from 
their primary responsibilities to perform appropri- 
ately in these roles, and must have the support of 
their management in this participation. Such sup- 
port could perhaps include rewards for participa- 
tion, but at the least must include an acknowledg- 
ment of the burden imposed by this additional task 
and the importance of some redistribution of 
ongoing responsibilities. 



Examples of typical members of the project 
management team might include key consumers of 
financial services (major academic departments, 
separate schools, divisions) as well as consumers of 
financial data (institutional research, budget office), 
representatives from key parts of the financial 
organization (internal audit, payroll, capital 
projects, purchasing), and staff from the technology 
organization who are knowledgeable about the 
institution's financial systems. Staff and user 
training are too often not addressed early enough in 
the project, so having the person who will later 
function as training coordinator serve as a member 
of the project team will help the team focus on 
strategies to meet training needs. Ideally, the "core" 
standing project management team should be kept 
to eight to ten people to facilitate frequent and 
constructive discussions; however, it is more impor- 
tant to ensure adequate representation for input and 
buy-in than to limit the size of this team, so a larger 
team may be necessary. 

The project manager must be able to work with 
the variety of individuals represented on the team in 
order to move the group toward accomplishing its 
common goal, taking maximum advantage of the 
skills of each individual member of the team and 
helping each member contribute all that he or she 
can toward achieving the project ends. At the same 
time, sensitivity to the team's needs for support, 
guidance, and refreshment is also required, so that 
burnout does not occur before success. 

Throughout the process, the project manage- 
ment team will report back to the steering commit- 
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tee, to ensure that its work is continuing to meet the 
institutional needs and goals that were initially 
articulated. In addition, these periodic reviews will 
give the steering committee an opportunity to 
reshape or redirect the project, should needs shift. 

In addition, the project manager — in concert 
with the project leaders — will have to align and 
integrate the disparate and complex elements of the 
project by managing the composition of and ap- 
pointments and charges to the various additional 
teams or subsets of project team members that will 
need to be appointed throughout the project. The 
membership of these teams needs to be flexible, and 
in many cases the same individuals will have a role 
to play on several of the teams. Having some dupli- 
cation of team membership can improve alignment 
of action and intent throughout the project. It is 
particularly helpful when selected steering commit- 
tee members serve on appropriate project teams. 

It is important also to ensure that the roles of 
the various teams are well understood and that 
reporting and communication lines are clearly 
delineated so that each major component of the 
project is appropriately managed and staffed. The 
work of the teams needs to move forward in a 
synchronized way; several of the teams may be 
working at the same time, and information must 
pass between them efficiently. 

Using Partnerships to Achieve Buy-in 

The reality of financial systems in complex organiza- 
tions today is that they serve many users, and are 
major tools in accomplishing many important tasks 
for the institution. As such, any project that will 
make significant changes in these tools needs 
continually, throughout the project, to promote a 
sense of " ownership" of that change across the 
institution. In addition, as the use and management 
of information become more decentralized across 
the institution, there are many different users who 
have knowledge to contribute to the project. Their 
expertise can be tapped, and their involvement and 
buy-in ensured, by creating a series of partnerships 
through the various additional teams that will be 
appointed throughout the project, building on the 
cross-institutional representation of the steering 
committee and project management team. 

Depending on your institution's culture, ideally 
the chief financial officer (CFO) or chief budget 



officer (CBO) will enjoy a good working relation- 
ship with the chief information technology (IT) 
officer. The roles of these different players, and the 
extent to which the CFO/CBO will influence tech- 
nology decisions, will be determined by the culture 
of your business/finance group. The financial 
organization will clearly have a project ownership 
role, and the project manager may want to encour- 
age the CFO to play a strong role in the technologi- 
cal discussions, as well. 

In a situation where the CFO or CBO is involved 
in the technology strategy, this participation can 
have significant influence over the strategic direc- 
tion of the project, particularly in the areas of 
development philosophy and distributed processing. 
Based on experience or vision, he or she may incline 
toward the purchase of applications from outside 
vendors, or the use of external development alone or 
in a partnership structure, in an effort to reduce 
dependence on the information technology organi- 
zation over the longer term. Alternatively, he or she 
may prefer an internally developed solution, so that 
the core financial processes of the organization can 
continue in as similar a manner as possible to 
current practice. From the perspective of the CFO, 
issues such as the ongoing support model for the 
financial organization, and the process used in 
developing the business requirements for any 
technological solution, will be key. 

Whatever the particular mix of participation, 
such a high-level "partnership" between the finan- 
cial management group and the information tech- 
nology organization will go a long way toward 
cementing the change process and marshalling the 
necessary resources to successfully complete the 
project. Fostering this particular partnership will 
also help to avoid a major project land mine — the 
failure of technical staff and business staff to agree 
on the requirements of the specified system. 

Without this understanding, the project goals 
cannot be defined in a way that will be seen as 
meeting "institutional" needs, since different parts 
of the institution will be perceiving the needs 
differently, thus preventing effective evaluation of 
available tools, setting of project goals and mile- 
stones, and clear and consistent definition of needs 
for vendors (when external solutions are sought). 
This potential land mine can best be managed by 
providing as much education as possible for all 
interested parties on campus, so that the under- 
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standing of what already is being done, what 
changes are to be introduced, and what tools are 
available to introduce that change are not pieces of 
information held by only one or two groups, but 
fashioned by all members of the various teams 
working together in appropriate partnerships. 

Using these partnerships effectively is a key to 
the success of the project, whether they are between 
technologists and end users, the chief information 
technology officer and the CFO, technologists who 
are focused on client/server-based implementation 
strategies and those who are more oriented toward 
mainframe applications, those who benefit from 
transaction processing systems and those who are 
more concerned with reporting and manipulation of 
data, or within staffs of different end-user depart- 
ments. All of these partnerships will need to be 
strengthened and refined as the project moves 
forward. 

Pelteirinmmnirag tUhe Scope off fflhe Pirojecff 

Two fundamental issues to consider when acquiring 
or developing any automated system, especially a 
financial system, are: (1) the importance of recog- 
nizing that technology should not drive the systems 
acquisition process, but should be viewed as second- 
ary to the actual business processes that it will 
support; and (2) the importance of ensuring that the 
institutional business processes and practices are as 
efficient and effective as possible. 

Depending upon the principles established by 
the steering committee and the directions that 
group has set, the project management team will 
need to choose an approach to identifying business 
requirements for new or enhanced systems. In the 
traditional method of business requirements deter- 
mination, the existing business functions are 
analyzed and the specific needs of each application 
are documented as requirements. 

An increasingly popular approach, arising from 
continuous improvement or quality management 
concepts, is to review existing business processes 
prior to defining business requirements. These 
reviews often include participation from cross- 
functional teams and identify possible significant 
improvements in existing processes that might 
reflect cost containment, additional services, or 
more efficiency or effectiveness. Depending on the 
thoroughness of these reviews, the overall process of 
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change can be slowed down by process reengineer- 
ing efforts; for institutions intending a significant 
paradigm shift, the longer lead time required for 
these detailed reviews is a cost to consider. Regard- 
less of the level of effort devoted to these reviews, 
the technological evaluation will need to take into 
consideration these newly defined needs. 

Clearly, not every institution will be able to or 
need to conduct extensive business process reviews. 

If, for example, the steering committee vision 
process has resulted in a strategy that would point 
toward purchasing an off-the-shelf system, such a 
purchased system may not be able to provide the 
highly customized functional features that are likely 
to be specified in a process evaluation exercise. In 
fact, to fully leverage a vendor product, it is often 
necessary to adapt business processes to fit the 
product. Like the steering committee, the project 
management team must recognize this at the outset 
and make sure that any process evaluation is con- 
ducted with appropriate expectations, that is, 
understanding that not all sought-after functionality 
may be possible with a purchased solution, and, in 
fact, that business process change will likely be 
influenced by the nature of the selected product. 

Even when major process changes are not 
anticipated, it is nonetheless valuable to engage in 
some business process evaluation while taking a 
more traditional approach to identifying required 
functionality. Clearly, the business process evalua- 
tion effort, which will prompt broader recommen- 
dations than simply the use of new technical tools, 
will not be solely dependent on eventual responses 
to a request for proposals for the implementation of 
changes. Indeed, some of the recommendations for 
process change can often be introduced before any 
other significant changes are made, producing the 
"quick wins" that enable customers to believe that 
the project will, over time, make significant changes 
for the institution. The project management team 
can be working with the appropriate managers and 
offices to introduce such non-technology-driven 
changes, regardless of the outcome of the systems 
project. 

In deciding what approach to take to identify 
business requirements, the institution's leadership 
must be aware that the costs of introducing new 
technologies to support the old way of doing 
business — "paving cowpaths" — can include both 
the inflexibility of the resulting system and the 
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suboptimization of the resulting processes. Oppor- 
tunities for introducing institutional change of the 
scope required by migrating or replacing financial 
systems, as well as by making financial business 
process changes, are not frequent. Attempting to do 
one, and then returning later for the other, may 
require more upheaval than the campus can tolerate. 

IEsttaMnsMimg a Pimjject PHaim 

Before proceeding with the actual formation of 
additional teams, the project management team will 
need to establish an initial project plan, made up of 
a preliminary timeline and an initial estimate of 
resources needed for the project. Creating such a 
plan will provide a sense of the resource commit- 
ment that will be necessary to accomplish the 
steering committee's goals in a reasonable time. The 
initial project plan will then need to be presented to 
the steering committee for its approval. 

In pulling together this project plan, the team 
will have an opportunity to further define the 
project. Important questions to answer will include 
who really "owns" the project, and who really 
"funds" the project. If the functional office 
(through the CFO and/or CBO) assumes primary 
ownership, the value of technical expertise may be 
underestimated, but the enhanced buy-in from end 
users will be valuable in achieving success; if the 
technology office takes primary ownership, project 
management skills may be stronger and the techni- 
cal issues will be well addressed, but there can be a 
cost in achieving an appropriate functional focus. 

In designing the funding strategies, user-funded 
projects can produce high acceptance of the impor- 
tance of the project, joint funding can produce some 
conflict over priorities, and core funding can pro- 
duce concerns for control of costs. All of the fund- 
ing and ownership models can be successes or fail- 
ures, depending on how they are articulated and 
managed, and how they conform to the 
institutional culture. 

The preliminary project timeline should reflect 
the major phases of the project (conducting business 
process and technology reviews, generating a re- 
quirements document, issuing a request for informa- 
tion/request for proposals, selecting a solution, and 
implementing the system), and indicate which 
phases can run in concert and which are "gating" 
items for future steps, with rough estimates of the 



amount of time necessary for each. These time esti- 
mates should incorporate the assumptions about 
available resources included in that part of the plan. 

The resources plan, which will of necessity be a 
rough approximation of anticipated needs, should 
reflect both one-time expenses (such as initial 
hardware and software purchases) and the ongoing 
costs (such as maintenance, training, and eventual 
equipment replacement). As mentioned earlier, 
training, in particular, is an area too often over- 
looked in the cost analysis. The plan needs to 
address how it will be funded initially, how long it 
will be necessary to offer training, and what kind of 
resources will be needed to support maintenance of 
the training function. 

The costs of the project need to be broadly 
articulated for the entire institution, so that person- 
nel impacts from across the institution are included, 
as well as other resource allocation choices such as 
assignment of space. If systems will be running in 
parallel for some period of time, the cost of support- 
ing both systems will need to be reflected. Likewise, 
if part of the project strategy is to distribute work 
flows in a more decentralized way, any burden of 
that "incremental" work on the decentralized units 
needs to be reflected in the project's resource plan. 

The resource planning should also reflect 
realistic assessments of the project benefits, to 
manage the full impact of the project. There may be 
benefits from the project that are seen as key but 
that are without direct budgetary impact (for 
example, increased quality of service to customers); 
for these benefits, appropriate indicators of success 
(customer survey responses, reduced number of 
complaints, decreased cycle times) should be 
established at the outset, to provide a matrix within 
which the team can report on progress toward goals. 

The resource allocation choices in support of 
the project need to be made and managed within the 
context of a set of outcomes and an assumption 
about timing of milestones. If changing institu- 
tional priorities require that the resources available 
be reduced, the project team must define a reduced 
set of goals, or set a longer time frame for the 
achievement of the goals, or perhaps a little of each. 
These revisions to the context of the project must be 
seen as part of a cohesive whole, so that those who 
are relying on the outcome of the project have a 
continuing, realistic understanding of what will 
happen and when and with what degree of support. 
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Clearly stating this set of assumptions at the 
outset will help to avoid a significant project land 
mine, that of embarking on the project with an 
unrealistic assessment of the formula, "resources 
plus time equals outcomes." Underestimating (or 
not fully reflecting) the resources or the time 
necessary to achieve the agreed-upon outcomes will, 
without exception, produce a project that is unreal- 
istic to complete, and will at best put the project 
owners in the position of constantly managing 
immense frustration and unplanned resource 
reallocation in order to achieve a reasonable out- 
come. At worst, the project will be brought to a halt 
over the inability of project management to meet 
the agreed-upon goals with the agreed-upon re- 
sources. 

This risk must be managed through a variety of 
strategies: 

• establishing a project plan with resource re- 
quirements tied to particular project goals, so 
that as time passes and money is spent, if the 
goals are not being met, there is an obvious 
indicator that the estimates are not realistic; 

• studying general project management informa- 
tion that provides strategies on how to estimate 
and manage resources for projects of this type; 

• conferring with other institutions that have 
embarked on similar projects and talking to 
vendors, to get as realistic an assessment of the 
resource needs as possible; and 

• reviewing the history of the institution in 
managing similar projects in the past, including 
the level of commitment that has continued 
over time and the quality of the initial estimates 
compared to final experiences. 

In planning funding for the project, it is impor- 
tant to include the impact of any financing strategy 
on the project outcome — if funding sources are 
going to be available over time, the major expense 
components of the project must parallel these 
funding streams, or temporary funding sources 
must be identified at the outset. Establishing the 
major milestones of the project, both with absolute 
dates and as they are tied to other earlier deadlines, 
will allow the community to incorporate the project 
work into other institutional priorities. 
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Employing Good Management 
Strategies 

Whatever approach is taken in identifying require- 
ments and establishing business needs, there are a 
number of good project management strategies that 
are especially critical in a campus financial systems 
project and that need to be employed throughout 
the life of the project. These include teamwork/team 
building strategies, communication strategies, 
strategies for resolving differences, change manage- 
ment strategies, progress management strategies, and 
strategies for managing expectations. 

Teamwork/team-building strategies 

As pointed out in earlier chapters, creating and 
using teams of people to accomplish the 
institution's goals is a critical success factor for any 
systems project. The effective use of teams requires 
a set of skills on the part of the project manager/ 
team leader, as well as each member of the team. 

The project manager, or leader of any of the indi- 
vidual additional teams, will be called upon to 
facilitate discussions and help the group move 
toward consensus; to establish clear goals for the 
group, and provide a role for each member that 
takes maximum advantage of his or her skills in the 
team's area of responsibility; to provide structure for 
team meetings, including an agenda for the meeting 
and clear starting and ending times; to set a tone for 
the discussion that allows participation from all 
members of the group; and to summarize the work 
of the group in order to provide information to 
other teams as well as to the larger campus commu- 
nity. 

Each individual team member must bring a 
willingness to participate in a group setting, and to 
respect and participate with the other members of 
the group; an ability to represent his or her particu- 
lar area of expertise, while also keeping the steering 
committee's larger institutional vision in mind; an 
endorsement from his or her supervisor of the 
importance of the team's work, so that appropriate 
amounts of time and energy can be devoted to the 
group by all team members; and a level of knowl- 
edge and expertise about the project at hand, or the 
willingness to become better informed by pursuing 
additional information as necessary. 

Understanding how to work on a team is of such 
importance that it is worth considering providing 
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the opportunity for team members to do formal 
team training. At the University of Idaho, for 
example, information systems staff learned team 
skills by completing two twelve-week team-training 
courses through distance education from the 
National Technological University. The skills they 
developed helped them when they later used teams 
to implement several modules of an integrated 
information systems package. At the University of 
Michigan, the information technology organization 
has identified a staff function called Professional 
Development Managers; these individuals work with 
technology staff on an ongoing basis to help them 
develop teamwork and communication skills. 

Communication strategy 

Involving institutional players in the teamwork 
effort means being sure that good information, and 
complete information, is being shared often and 
well with all interested parties at the institution. 
Ensuring that all constituencies hear about the 
project, in ways that are tailored to their involve- 
ment with the outcome, is a critical success factor. 
The project team must understand the difference 
between information sharing with all parts of the 
institution and project management reporting for 
those who have a direct investment in the outcome 
and/or are involved in moving the project forward 
toward its goals. In particular, the project manage- 
ment team (or a subset of the team focused on 
communications) is responsible for ensuring appro- 
priate levels of communication among the various 
teams who are involved in the project, so that 
business process teams, the technology evaluation 
team, and the steering committee are all connected 
to and informed about each other's work. 

Unfortunately, part of any communication 
strategy must include dealing with complaints. They 
will happen, so having a thoughtful approach in 
place will solve problems more quickly when they 
arise. At Wayne County Community College, a 
financial systems implementation employed a 
"committee on gripes" to provide a special mecha- 
nism for complaints to keep these kinds of issues 
from taking up valuable project team meeting time. 
Many complaints can simply be forestalled by clear 
communication about the goals and timetable of the 
project from the start, so that at least confusion or 
lack of understanding are not significant factors. 
However, there will be some areas, offices, and 

45 



individuals for whom the project does not have 
material advantages, and who will have criticisms of 
the methodology of management, the approaches, 
and so forth. It is important to take these risks into 
account at the start, and anticipate complaints so 
that reasonable responses can be made, especially as 
the stress of implementation approaches. 

Strategy for resolving differences 

As business processes and the underlying 
technology tools that support them become more 
decentralized, just as the "owners" and stakeholders 
of a financial system are spread throughout the 
institution, so too are the players who can effec- 
tively derail an implementation project. 

Obstacles to the success of the project can arise 
both from the personal perspectives of the individu- 
als involved and from their institutional responsi- 
bilities. For example, differences of perspective over 
security of data versus easy access to information, or 
decentralized processing of data versus centralized 
responsibility for the quality of that data, are 
perfectly reasonable given the variety of perspectives 
from which team members will be drawn. 

Such fundamental differences can constitute a 
project land mine if the project team fails to ensure, 
first, that such differences are seen as differences 
only, not judgments of right and wrong, and, 
second, that there is a project framework in place 
that includes a mechanism for the resolution of such 
differences. This can be handled by the project 
management team itself, or referred to the steering 
committee or some other authorized body, but the 
mechanism must be easily accessible so that the 
resolution of these issues does not slow down the 
overall progress of the project. 

Change management strategies 

The project management team, and the project 
manager individually, will both be called upon by ' 
the force and scope of this project to represent and 
articulate the need for profound changes for the 
institution, by the very nature of replacing financial 
systems. Leading this effort will require a level of 
institutional credibility and respect for the individu- 
als involved, constant communication with the 
stakeholders throughout the institution, and 
willingness to explore a variety of solutions in order 
to be able to clearly articulate the appropriateness of 
the final recommended solution. 
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In addition, all members of the project teams 
will need to be able to withstand pressures to slow 
down or derail the change process, as well as deal 
“with attempts to change the project scope for 
political reasons or in reaction to a perceived crisis. 
Clearly the project manager and team members will 
need the support of the steering committee as they 
continue to pursue this high institutional priority. 

Progress management strategies 

To ensure that the project moves toward success- 
ful completion, the project manager will need to 
employ a variety of progress measures. These will 
include setting key milestones for the project (such 
as completion of the business process reviews or 
drafting of the request for information document), 
and then working with the specific teams to set 
more detailed task lists and deadlines for each area 
(for example, each business process review will have 
a set of tasks that must be completed to prepare the 
needs recommendations). 

As outlined in the project plan, these milestones 
should be tied, whenever possible, to necessary 
resources, so that the project management can 
measure whether the resources devoted are produc- 
ing the products required. The more such milestones 
with affiliated resources can be established at the 
outset, the easier it will be to diagnose if the project 
is not going to be able to meet its larger end goals, 
and to take corrective action well in advance of 
reaching such a crisis. 

In addition, the project manager should be 
responsible for managing the project resources 
themselves, administering the staff and equipment 
budget, monitoring the expenditures of outside 
consultants, and working with the individual teams 
to ensure that their activities are funded and man- 
aged appropriately. 

Finally, the project manager may wish to use 
outside parties to review the project's progress. In 
this case, the outside group or groups involved — 
probably from the institution's outside audit firm or 
technology consulting firm — should review the 
initial project plan to identify any problems as 
quickly as possible, as well as to help prepare 
interim reviews as the project moves forward. Such 
reviews may be formal visits to campus to meet with 
project teams, or may be done on a more informal 
basis by reviewing project notes and reports and 
talking to individual team members as necessary. 
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Management of expectations 

A major critical success factor in managing the 
project is the effective management of expectations. 
This includes not only setting the expectations of 
those involved in the project to keep the project 
planning realistic and within achievable scope, but 
also setting the expectations of the broader campus 
community about the scope of the project and its 
resulting impact on the way the institution does 
business. 

In defining the project scope at realistic levels, 
there will be constant pressures to expand the 
boundaries of the project, as each of the institu- 
tional areas with which the financial systems 
interact is analyzed and considered. While each of 
these expansion decisions will be perfectly defen- 
sible in its own right, the breadth of the project 
cannot be allowed to exceed a realistic scope for an 
institution that has many other competing claims 
on its energies. It will fall to the project manager to 
constantly exercise restraint in refining the project 
goals to keep them both complete and realistic. 

In setting expectations, the whole institution 
will be affected to some extent; all of the members 
of the teams defined above will have at least some 
portion of their time consumed by this new en- 
deavor, so some component of their existing work 
will either fall to other individuals, or not be 
performed as the institution has been expecting in 
the past. Ensuring that the campus community 
understands the longer-term advantages of the 
project and therefore can revise its near-term 
expectations will avoid burnout on the part of the 
team members, as well as disappointment on the 
part of the campus community about the inconve- 
niences presented to their lives and work. 

By raising the consciousness of players as to 
what is possible and desirable, and clarifying the 
difference between a wish list for "what technology 
could do" and a needs assessment for "what we are 
looking for in this implementation," the project 
management team can ensure that the particular 
project outcomes will be understood to match 
institutional requirements. 

When all functionality cannot be met by the 
initial system implementation, expanding expecta- 
tions or needs can be noted for possible attention in 
a subsequent, post-implementation phase. At some 
point, it may be possible to "grow" the new system 
to provide additional functionality; if so, keeping a 
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Figure 4: Process flow chart for project management 
— from project plan to implementation 
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Structuring and Managing the Project 



Critical Success Factors: 

/ Appointing the right project manager 
/ Appointing teams that foster 

partnership and collaboration, building 
on campus expertise and experience 
/ Clearly defining roles and 

responsibilities of all participants 
/ Establishing major project milestones 
with specific dates and resources 
required for completion 
/ Effectively managing expectations of 
project outcomes 

/ Keeping different groups within the 
community informed in ways that are 
meaningful to them 
/ Having a mechanism for resolving 
.•differences 



Y4-' Containing the scope of the project to 
can realistically be accomplished 




Land Mines: 

/ Allowing the project scope to expand 
beyond capabilities to get the job done 

/ Failing to engage ail key stakeholders 
appropriately 

/ . Inability of team members to 
understand the institutional 
perspective 

/ Unrealistic expectations of the ease 
with which systems can be imple- 
mented 

/ Failing to understand that the system 
may not meet all needs 

/ Underestimating the resources and 
time needed to complete the project 
Allowing conflict to go unresolved,.. 
especially between the chief financial... 
officer and the chief information : ' ' ? I • 
technology officer' j 



record of needs that could not be met in the initial 
implementation will provide a foundation upon 
which to build later. A note of caution: This should 
not be confused with an invitation to freely add 
new functionality to the selected system as it is 
implemented, but to note the potential for improve- 
ment when the opportunities arise at a later date. 

One potential land mine for a project that has 
heavily engaged users of business processes to 
reevaluate those processes — and define their needs 
■ based on making major changes to those processes — 



is the potential that a product cannot be found in 
the marketplace that will provide the required 
functionality, yet the institution may not have the 
resources to develop the systems in-house. The 
project management team must take extra care in 
clearly communicating this possibility to business 
process teams, and emphasize the importance of 
their role in identifying "must have" functionality 
and prioritizing requirements so that the most 
critical functionality can be met with the initial 
implementation. 
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Chapter IV 
Overview 



♦ Structuring for Business and Technology 
Evaluations 

♦ Evaluating Business Processes 

♦ Evaluating the Technology Environment 

♦ Identifying Disconnects and Proposing 
Alignments 

♦ Creating a Requirements Document and 
Finalizing the Project Plan 



"... the technology team and business 
process team(s) should work in parallel , 
reviewing the recommended process 
changes against available technology 
tools, and revisiting both sets of 
information until the two visions can be 
aligned ..." 






IV: Determining Business and 
Technology Requirements 
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he approach advanced in this book for 
determining business and technology 
requirements for a new or upgraded 
financial information system is to take 
the opportunity presented by the project to care- 
fully evaluate your current business practices and 
processes in conjunction with investigating poten- 
tial technical solutions. This is an excellent oppor- 
tunity to introduce business process change as well 
as technology change at your institution. 



Structuring for Business and 
Technology Evaluations 

The most common structure for accomplishing a 
business process review is to form a number of 
process evaluation teams around the major business 
processes that will be affected by the software 
replacement being considered. In conjunction with 
this activity (or a simpler business requirements 
approach, if that option is selected), a technology 
evaluation team will also need to be formed to work 
closely with the business teams to develop proposals 
that will align the institution's information technol- 
ogy infrastructure with identified strategic direc- 
tions and business requirements. 

If your institution has not been previously 
involved in business process review efforts, it may 
be useful to bring in an outside consultant or peer 
manager from another institution, who can provide 
some initial training and exposure to the issues to 
be addressed and examined. In addition, as recom- 
mended earlier, it will be important to provide some 
training in the skills needed for working in a team 
environment, as often the people responsible for 
transaction processing in financial organizations 
have not previously been exposed to such skills and 
these will be key players in the process reviews. 

The work of the business process evaluation 
teams will be taking place in concert with the 

O 




technology evaluation, with frequent interaction 
between the technology team and the business 
process teams. This will enable the evaluation of 
available resources for the highest priority redesign 
proposals, as they are discovered, and will ensure 
that the suggested process changes are supportable 
with existing tools. The technology evaluation team 
will build on the work of the business teams as they 
move forward, as well as articulate the existing 
institutional technology environment and investi- 
gate the technology marketplace, within the context 
of the institution's broader technology strategy. 

Depending on the scope of the project or size or 
complexity of the institution, it is quite possible 
that the project management team might choose to 
establish a single evaluation team, charged with 
both business process and technology evaluation. 
The functions described for the business process 
teams thus would be combined with those described 
for a technology evaluation team, and the combined 
team would progress through the business and 
technology evaluations together. For example, at 
Sinclair Community College, during the evaluation 
phase the technical staff (the systems analyst for the 
business area) prepared a draft of the business 
functions and features which the business staff 
validated, revised, and updated. This process, in fact, 
was also used to identify gaps in the existing system 
and propose additional functions and features for 
the new system. Similarly, at San Jose State Univer- 
sity, the module "owner" prepared the needs 
analysis and the systems analyst interpreted it into a 
possible solution, which was then negotiated to the 
actual solution. 

EvaHunMmmg Eknsmniess Processes 

Evaluating business processes is related to a variety 
of concepts in the business world — total quality 
management (TQM), work flow redesign, systems 
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design (referring to more than just computer-based 
systems), business process reengineering (BPR) — 
and all have been carried over to the higher educa- 
tion community to some extent. Any of these 
constructs or techniques can be used to achieve the 
necessary goal of examining the processes at hand 
and the purposes for which they are used, to think 
"outside the box" about refining the processes to 
achieve their goals more efficiently and effectively. 

A variety of factors can prevent an institution 
from using "hot" new management tools effectively 
— lack of appropriate training in how to apply the 
models; a resistance to change from key stakehold- 
ers of the processes being reviewed; lack of support 
for such study from institutional leaders; disagree- 
ments within the campus community about the 
necessity for change in these areas; and being 
overwhelmed by the jargon and exercises of the 
models, to the point where it is not possible to 
produce an effective study and report. In fact, it is 
better to adopt the tools of these disciplines and 
eschew the jargon wherever possible. 

Managing all of these risks, in order to get 
maximum advantage from the process review, is one 
of the critical success factors in the business evalua- 
tion process stage of the project. 

Involving the "Right" People 

The primary work of the business process 
evaluation teams will be performed by the line 
workers from the financial areas and the "customer" 
units, supplemented with information technology 
staff as appropriate. These teams will later form the 
basis for implementation partnerships, so an effec- 
tive working relationship developed at this stage of 
the project will facilitate the implementation pro- 
cess, as well. 

Managers within the financial units should also 
be involved in reviewing the work of the teams and 
providing clarification when necessary, although 
their role must not interfere with fully recording 
both the current practice and that which would be 
preferred. (See the sidebar beginning on the next 
page for a suggested composition of teams that 
might be formed to evaluate a number of common 
business processes.) 

While outside consultants may be useful in 
shaping the process by which the business analysis 
is performed, the resulting product must be one that 
is institution-specific, and thus one that is fully 



shaped by institutional players. Having appropriate 
members of the community involved in these efforts 
will be key — senior managers must demonstrate 
ownership of the process and support for the 
outcome, while managers of the financial units will 
need to set priorities for change and provide guid- 
ance to the overall process. 

Users and providers of the services, both cen- 
trally and in the core academic units, must also be 
involved in the analysis of the status quo and the 
structuring of alternative methods of doing busi- 
ness. The introduction of new ways of processing 
transactions or passing data is trivial compared to 
the challenge of new ways of administering the 
overall processes of which these transactions are a 
part, and the data that result. Business process 
redesign needs to be "customer driven," and cus- 
tomers are everyone involved in a process and its 
outcomes. In the final analysis, success for this part 
of the project will be driven by the functional users 
of the systems, not the technologists who support - 
the systems. 

Involving all these key players in the review 
process will result in significant success in effecting 
change in the institution. If the stakeholders have 
participated in the business process evaluation and 
see that the proposed changes will better enable 
them to be served by "the system," they will become 
the strongest advocates for the changes being 
recommended, which will move the implementation 
project forward more swiftly. If they do not feel that 
they have been consulted, or do not see that the 
recommended changes will make any significant 
improvement in reaching their goals, the implemen- 
tation process will be long indeed, and possibly 
destined for failure. 

Selecting the processes 

In most institutions, the financial business 
processes to be evaluated will include: 

procurement/payables 

• general ledger accounting 

• personnel/payroll/benefits 

• receivables 

• investment/gift accounting 

• financial reporting/decision support 

While sometimes dealt with as part of the 

student system, the financial aid process may also be 
included in the financial business process review 
depending on the organizational structure and 
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institutional culture. In addition, the physical plant 
area may or may not be viewed as part of the 
.financial processes, including maintenance schedul- 
ing, work orders, and stores management and 
supplies inventory. Other functions that might be 
included are operating and/or capital budgeting and 
planning (increasingly important functions that 
need to be integrated), grants and contracts manage- 
ment, and inventory and fixed assets. 

In determining which processes to evaluate, it is 
important to conduct a scan of the external environ- 
ment to learn from the experiences of peer institu- 
tions that have engaged in business process reengi- 
neering. This effort is both a time-saving and stress- 
saving device, as well as a strategic exercise that will 
enable the project management team to focus 
quickly on areas where the process will have an 
optimal chance of success. This external scan will 
provide an opportunity to see what has worked for 

. other institutions and businesses, and what have 
been pitfalls or areas of material challenge. It is also 
valuable to review best practices in industry to help 
define the state of the possible. 

In addition, other broader institutional priori- 
ties outside of the financial systems project must be 
taken into account when defining the nature and 
scope of the process evaluation effort. Are there 
other process evaluation projects planned or ongo- 
ing in other areas of the institution, and if so, how 
does the financial project complement or contrast 
with those? As the process evaluation effort makes it 
possible to more closely match current institutional 
needs with current technological realities, an 
understanding of which areas are of most institu- 
tional significance will be crucial when deciding 
which problems to solve first and most completely. 
— Indeed, the-strategic selection of appropriate 
processes for review and potential change can help 
to avoid another project land mine, that of focusing 
efforts on an area that is not important enough. It is 
often tempting to select a project that is viewed as 
"stand-alone" or "lower priority" in order to de- 
crease the pressure for success. Unfortunately, this 
also decreases the interest in success and makes it 
harder for the resulting changes to be accepted, 
since they are not seen as being of significant import 
to the institution’s overall mission. Although 
financial systems are often viewed as an institu- 
tional priority, that is not always true, and within 

the general rubric, some svstems can be viewed as 
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Potential Business Process Teams 

/ Procurement/payables 

This team should include purchasing buyers, dis- 
bursements clerks and managers, departmental admin- 
istrators who are responsible for departmental purchas- 
ing; representatives from shipping/receiving, and per- 
haps some faculty members who are involved with pro- 
curement for sponsored research projects. This team 
will need to evaluate and recommend changes to the 
way the institution requisitions, purchases, receives, in- 
ventories, and approves payments for goods and ser- 
vices, examining the roles of the different offices and 
individuals, the institutional needs being met by each 
step, the amount of approval and control that is neces- 
sary, and alternative processes that could be used. The 
priority, as with each of the business process evalua- 
tion teams, is to continue to meet institutional require- 
ments with a minimal amount of duplication of effort, 
exploiting technology tools as facilitators in gathering, 
processing, and using data. 

/ General accounting 

This team should include representatives from the 
accounting office who have responsibility for generat- 
ing the institution's financial statements, individuals 
from departments and schools who provide and sup- 
ply accounting information within their areas, internal 
audit staff if available, budget/financial analysis pro- 
viders, and others from departments who are regular 
users of the institution's financial records (such as the 
fundraising office, the president or governing board 
area, major research centers, and so forth). This team 
will evaluate the institution's current chart of accounts 
and accounting transaction management, and recom- 
mend necessary changes to the chart and to the pro- 
cessing of transactions, both for financial reporting pur- 
poses and for day-to-day management. 

/. Personnel/payroll/benefits 

This team should include representatives of the 
human resources area, particularly those involved with 
the addition and deletion of employees from institu- 
tional records; managers and clerks who deal with the 
generation of paychecks for faculty, staff, students, and 
other affiliates of the institution; representatives of the 
benefits processing area who rely on payroll/ person- 
nel records for eligibility information; department ad- 
ministrators who feed payroll information on individual 
employees into the payroll system, both from major 
institutional units who process significant amounts of 
information and from smaller units whose challenges 
will.be of a different magnitude; and representatives 
from the institutional research area or other of fices who 
rely on this information for counts of employees, dol- 
lars spent, benefits accrued, etc; This group will need 
to consider how employee data move from - inception 
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to paycheck, benefit accrual, and termination, and con- 
sider all the appropriate subsystems that support these 
processes. 

/ Receivables 

This team should include representatives of both 
the general receivables and student receivables opera- 
tions, as well as the financial aid area; administrators 
from departments that are major suppliers of services 
and therefore rely on the accounts receivable opera- 
tion; institutional research and budget/financial analysis 
representatives who will rely on this information (par- 
ticularly student receivables data) in projecting the fi- 
nancial status of the institution; and representatives of 
affiliated areas who receive bills from the institution 
for the provision of services (e.g., student organizations 
that are separately incorporated, purchase services from 
the institution, and are billed through the receivables 
process). This group should examine both how trans- 
actions are entered (as well as how the delivery of these 
billing services is perceived) and the methods of ac- 
cessing and using the resulting data. 

/ Investment/ gift accounting 

This team should include representatives from the 
investment management function, individuals from the 
general accounting area who rely on the investment 
reporting structure for financial reports, fundraising of- 
fice representatives who have some responsibility for 
gift processing and reporting, representatives of affili- 
ated institutions who may process their own fundraising 
proceeds, those responsible for cash management of 
the institution, a representative of the cashiering func- 
tion, and an internal audit representative if appropri- 
ate. For some institutions, a connection with the work- 
ing capital and/or custodian bank will also be helpful. 

✓ Operating and capital budget/planning 

This team should include budget/financial analysts, 
administrators from both large and small departments 
who are responsible for the generation and submittal 
of departmental/school budgets, representatives of the 
facilities area who manage capital projects, and those 
from the investment area who are responsible for the 
management of capital funding sources. 

✓ Grants and contracts management 

Representatives from departments who are major 
generators of grant and contract activity should make 
up the bulk of the team. In addition, it will be useful to 
include representatives from the general accounting 
area who incorporate this information into the institu- 
tional financial statements, representatives from the 
receivables area who are responsible for the process- 
ing of funding requests to sponsors, and representa- 
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tives of the payroll/personnel and procurement teams, 
as these are major service areas to grant and contract 
activity. Finally, representatives of the areas that handle 
the "pre-award" grant and contract activity will be im- 
portant, as well as faculty members who serve as princi- 
pal investigators and therefore have frequent interac- 
tion with both the "pre-award" and "post-award" pro- 
cesses at the institution. 

/ Inventory/stores 

Department administrators responsible for the or- 
dering and receiving of equipment, hazardous materi- 
als, animals, and other major procurement items, as well 
as purchasing office representatives, accounts payable 
representatives, and those who handle any on-campus 
distribution and/or stores inventory should be included. 
Again, faculty who are responsible for sponsored re- 
search procurement may be helpful in evaluating these 
processes. 

/ Financial reporting and decision support 

This team should include representatives from de- 
partments who are regular users of the institution's fi- 
nancial data, such as the fundraising office, the execu- 
tive or governing board area, the budget office, and 
institutional research and planning, as well as mid- and 
upper-level managers who need access to institutional 
information in order to manage and revise institutional 
operations. The team will focus on ensuring that the 
data-mapping exercise has fully captured all appropri- 
ate levels of data to be stored and retrievable, as well as 
considering what reporting and access tools will make 
the data — and metadata — most useful to institutional 
decision-makers. 

✓ Financial aid processing 

This team should include representatives from the 
financial aid area, the student receivables function, the 
student loan function, and the federal funding collec- 
tions function. In addition, representatives from admis- 
sions, the registrar's area, student employment, and per- 
haps some student advisory functions should be in- 
cluded, as well as some student consumers of the ser- 
vices being provided. 

/ Physical plant operations 

If facilities operations are considered part of the fi- 
nancial systems of the institution, this team should in- 
volve supervisors and workers in the trades areas who 
would rely on a work-order system and an inventory 
management system, representatives of departments 
who are consumers of these services as residents in cam- 
pus buildings, the facilities manager, and the business 
managers for the physical plant areas. 
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more significant than others. Focusing significant 
institutional resources — in the form of team 
involvement, report generation, and so forth — on 
" an area that does not enjoy significant institutional 
focus can produce a result that is of insufficient 
interest to merit additional attention and support. 

In a situation where several possible projects 
have equal importance or significance, choosing 
first the one with the greatest chance of success is a 
wise strategic move. Defining the business process 
targets realistically by identifying the key problems 
to be solved, and also those that are not going to be 
solved, prevents the business process evaluation 
effort from becoming overwhelmed by potentially 
competing problems. With an evaluation effort 
focused on too wide an area, the time between study 
and resolution will overtake the team's enthusiasm 
for being involved in such work, and all subsequent 
evaluations will suffer from lack of involvement due 
to project burnout. Keeping the analysis and results 
focused on key areas of the process under review 
both facilitates a sense of accomplishment on the 
part of team members and provides a useful and 
concrete product to be used in creating the require- 
ments document. 

Another strategy for keeping the chosen set of 
projects manageable in scope is to consider those 
areas that could be left in their current configura- 
tion, but interfaced to a new, redesigned financial 
process. This could require only the creation of a 
technological interface between a current system 
that will not be replaced and the newly implemented 
financial system, or it could mean creating a "pro- 
cess interface" feeding new processes that have been 
redesigned off of existing systems that are found to 
be relatively effective. The University of Delaware is 
successfully using this approach. 

Staying connected to the steering 
committee strategy 

Keeping the business evaluation process con- 
nected to the steering committee's strategy is 
critical to ensuring that the institutional values, 
principles, and priorities are well understood and 
incorporated into the planning and analysis. At the 
outset, institutional support for introducing signifi- 
cant change must be robust, since the natural 
reaction of many institutional players will be to 
doubt the wisdom of any significant process change. 
Without strong management support for introduc- 
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ing new ways of doing business, the evaluation will 
focus only on tinkering at the margin of existing 
processes, which will be both time consuming and 
of relatively little import. 

The analyses must address strategic questions 
about the present and the future of financial man- 
agement practices at the institution. Much of the 
general construction of these analyses can be based 
on the overall analysis performed by the steering 
committee in setting the larger goals for the project 
— the business process evaluation will build on this 
steering committee work by looking in greater detail 
at particular processes. 

Institutional direction is also an important 
component in structuring the business evaluation 
effort effectively. Is there an interest in redefining 
administrative priorities or organizational relation- 
ships (i.e., moving from a more centralized to a 
more decentralized responsibility center model) or 
in redefining the role of financial analysis and 
understanding in the decision-making of the institu- 
tion? There are no right or wrong answers to such 
questions, but the business process evaluation effort 
must be focused in a way that complements the 
future direction of the institution as a whole, as will 
have been reflected in the initial report of the 
steering committee. 

Finally, it is important to balance this project 
against other institutional priorities; by allowing it 
to expand beyond reasonable bounds, the level of 
change introduced to the institution may over- 
shadow any good done in these specific areas. 

Conducting the process reviews 

In conducting the process review, the business 
process teams are responsible for ensuring that two 
questions are fully and fairly answered: "What are 
we doing now?" and "What would we like to be 
doing in the future?" In evaluating business pro- 
cesses, key institutional players will be able to 
engage in "blue sky" discussions about ideal pro- 
cesses, followed by a comparison of such ideal 
processes to current practice, and a comparison of 
"blue sky" technology requirements to available 
technical tools. Redesigns of key business processes 
can then be recommended, presented in contrast to 
current practice, and grounded in the reality of 
available technology solutions. 

All members of each business process team 
should be involved in documenting, reviewing, and 
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recommending changes to the current process they 
are evaluating. These evaluations can be managed in 
as formal a way as "process flow documentation" 
sessions, supported by outside consultants and 
relying on full-day retreats and deliverable docu- 
ments; or they can be informal brainstorming and 
note-taking sessions convened over the course of a 
few weeks involving one or two staff from each 
financial processing unit (payroll, accounts payable, 
and so forth) — the level of formality of this process 
should be driven by institutional mores, expecta- 
tions, timeframes, and budgets. 

Each team, however, should complete its process 
by being able to describe the significant "inputs" 
and "outputs" for the process, the tools currently 
being used (technology-based or otherwise), and the 
expected new approach as described through text, 
visual mapping, or a combination. This process 
description should include information about the 
planned uses for technology in this new environ- 
ment, in enough detail to make the evaluation of 
currently available technologies possible. (See the 
sidebar below for an example of the evaluation of 



the procurement/payables process at a medium-sized 
institution.) 

A key component of this phase of the mapping 
process is "data mapping" or "data modeling" — the 
process of articulating key data elements that must 
be captured, stored, and managed, the purpose and/ 
or use of the data, and the rules for each of these 
functions. Including a data mapping process at this 
point will enable the business evaluation process to 
most effectively introduce changes, and will also 
ensure that the project meets key decision support 
needs for the institution. 

For example, Indiana University spent 18 
months doing data modeling with the departmental 
users before a request for proposals (RFP) was 
produced for its new financial system. While there 
was a lot of resentment at first about this potential 
waste of time, in the last analysis, there was almost 
universal agreement that it was a major factor in the 
ultimate success of the entire initiative. Both users 
and financial staff seemed to learn a great deal about 
how the process should work in the new system, and 
it made the RFP process easier and resulted in a 



Procurement/Payables Process Evaluation: Ah Example 




The procurement/payables team begins its work by con- 
vening for a half-day session to document the current 
procedures involved in requisitioning, purchasing, re- 
ceiving, and processing invoices for the major catego- 
ries of purchases at. the institution. This analysis in- 
cludes not only the technology tools but any other tools 
that are used in moving a purchase through the sys- 
tem. The analysis highlights major areas where sub- 
units of the institution use separate subsystems (e.g., 
— shadow procurement systems developed to maintain 
’ ~ encumbrance information). 

This documented process then is evaluated for ar- 
eas of maximum effciency/inefficiency and maximum 
cost, and each of these areas for opportunity is priori- 
tized: 

• - How important is it to the institution to replace 

shadow systems in individual units? 

• How important is it to reduce the need for paper 
storage in documenting purchasing requirements? 

• How significant is strict compliance with federal 
procurement regulations? 

• How many prior authorizations are necessary, and 
what role can post- versus pre-approval play? 

ERIC 



While these areas of opportunity are being analyzed, 
the technology evaluation team is exploring likely tools 
to assist in making significant process changes-e.g., elec- 
tronic funds transfer with vendors for payment of in- 
voices; electronic authorization of requisitions, pur- 
chases, or payments; and document storage and retrieval 
systems. 

The procurement/payables team then puts together 
a report that reflects the highest priority process changes 
and describes the technology tools necessary to support 
those changes. A preliminary analysis of the cost/ben- 
efit of these process changes also is prepared at this time. 
The technology evaluation team includes its analysis of 
which tools are most available, and which are most likely 
to be problematic in the current marketplace, so the 
project management team can see the correlation be- 
tween highest-impact changes and likelihood of avail- 
able tools. This analysis is then combined with those 
being prepared by the other business process teams, into 
a single requirements document that will form the basis 
of the request for information and, eventually, the re- 
quest for proposals that will be issued to potential solu- 
tion providers. 



55 





-ii : 



;‘ ! r» • 



l^g.Yl;-lr..)zazfctf aHt 



savings from dollars that would have had to be paid 
to the external partner had it not been done. 

It is also wise to consider the notion of 
metadata, i.e., data about data — what they mean, 
where to find them, how to interpret them, and so 
forth. As distributed reporting increases, end users 
must be educated about what the data mean, and 
there will need to be a way to maintain this informa- 
tion so that it is readily accessible by users. Purdue 
University, for example, uses the World Wide Web to 
provide easy access to its metadata with hypertext 
links to diagrams, examples, and high-level and 
detailed definitions to support both the novice and 
the expert user. Document management and genera- 
tion for the Web is an automated process, so it 
requires less maintenance. 

Given the future need for this kind of informa- 
tion, rather than adding it as an afterthought later in 
the process, the business process teams can be asked 
to develop documents in a prescribed format during 
their evaluations that could then be easily incorpo- 
rated into the later documentation and training 
materials. 

Reviewing the results 

When the business process teams have com- 
pleted their work, the resulting process redefinitions 
must be robust enough to reflect a significant 
rethinking of the business process involved, while 
continuing to function within the institutional 
climate. For example, if your institution has very 
centralized governance and systems, you may not be 
able to incorporate a highly decentralized procure- 
ment process within your operations without a 
significant impact on the work of the other units 
involved. 

This redefinition of process also must be 
flexible enough to be shaped by specific software 
solutions as they are selected. It is for this reason 
that the technology evaluation team and business 
process teams must work in tandem, with frequent 
sharing of information, and perhaps supplemented 
by strategies such as overlap in team makeup, so that 
this work can be completed in synch. 

This process of confirming the existence of 
technology tools that are consistent with business 
process recommendations represents a critical 
success factor for the project. Although any process 
evaluation effort will have as an early stage a "blue 
sky" exercise that imagines the ideal world of 
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completely revamped processes, it is important at 
some point in the effort to bring the recommenda- 
tions back to earth. 

When discussing technology tools, the project 
teams should be aware of the need to manage the 
institution's expectations about the use of those 
tools — that is, to be clear about the distinction 
between the existence of the technology and the 
institution's ability to use that technology to 
support change. The analysis of whether that 
technology exists in a form that is mature enough, 
well-supported enough, and robust enough to be 
used in whichever key institutional process is being 
examined is a continuation of the gap analysis 
that was part of the steering committee's work. This 
analysis should be performed relatively early in the 
process review, so that the work to create an imag- 
ined redesign remains firmly grounded in the reality 
of potential technology solutions. 

When the business team reports are in a repre- 
sentative semifinal state, they should be reviewed by 
the project management team to provide an oppor- 
tunity for cross-team integration, and then referred 
back to the steering committee to ensure that the 
recommended changes are within the scope of that 
committee's institutional vision. 

Communicating expected outcomes 

A key set of expectations that must be effec- 
tively managed in this stage of the project is the 
community's understanding of what difference the 
potentially redesigned processes will make in the 
life of the institution. A cost/benefit analysis can 
build a business case for introducing process change, 
but it can also set unrealistic or artificial goals for 
the project. Clarity from the outset about what 
"effectiveness" means at your institution — what the 
problems are for each process that need to be solved 
so that success can be defined and measured — is 
key in each process redesign analysis. Measuring the 
resulting redefined processes against the goals that 
were to be achieved in making change is a com- 
pletely appropriate reporting/management step, 
which enables all involved with the process to 
confirm that the appropriate outcomes were 
achieved. 

Particularly for processes that cut across a 
variety of traditional institutional boundaries, it is 
important for the broader institution to be kept 
informed of major recommendations, so that their 
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impact on other areas of the institution can be 
analyzed and integrated into ongoing plans. 

Of course, the extent to which process changes 
are deemed vital to the success of the project, and 
the availability of technology tools in the market- 
place to support those changes, will be key factors in 
the decision-making about whether to buy a system, 
develop or migrate systems in-house, or partner 
with other institutions and/or vendors to build a 
new product jointly. 

Evaluating the Technology 
Environment 

The expected outcome of evaluating the technology 
environment is the identification of a set of techno- 
logical alternatives, potential impacts, and recom- 
mendations to the project management team for 
inclusion in the requirements document. The work 
of this phase is performed by a technology evalua- 
tion team — appointed by and including some 
members of the project management team — whose 
overall goal is to develop proposals necessary to 
align the institution's IT infrastructure with the 
strategic direction and business requirements of the 
financial systems project. To develop these propos- 
als, the team will: 

♦ assess the technological scope of the project, 

♦ identify possible technological alternatives 
through technology awareness-raising, 

♦ document the institution's existing technologi- 
cal environment, and 

♦ collaborate with the business process evaluation 
teams to assist in the articulation of realistic 
and supportable (with technology tools) 
process change recommendations. 

The composition of the technology team must 
balance strong technology leadership with equally 
strong business representation. Such strong technol- 
ogy leadership is essential, particularly when there is 
a greater paradigm shift required (for example, if the 
steering committee gap analysis has identified a 
large gap between the current mainframe environ- 
ment and a proposed client/server technology 
strategy), and the team members will need to arrive 
at a consensus. 

The team will need to become thoroughly 
familiar with current and emerging technology 
products and trends, especially those in the pro- 
posed environment. In particular, an IT staff mem- 
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ber familiar with the existing financial system 
applications should be assigned to the team. IT staff 
representation on the team should include both 
"desktop" expertise and "data systems" expertise, 
especially if the technology direction of the institu- 
tion as a whole assumes a move toward distributed 
solutions. Equally strong business representation on 
the technology team will provide necessary user 
insight into the issues related to the institution's 
installed systems and the viability of any proposed 
new technology. 

The technology team will likely look at current 
systems from a technological standpoint rather than 
from the view of the business processes that the 
technology supports. As an example, the documen- 
tation of the existing IT environment would iden- 
tify the hardware, software, file sizes, production 
times, number of online users, response times, and 
other information of this nature, but would not 
necessarily identify the functional processes pro- 
vided by the technology, such as processing checks 
for accounts payable every day versus every two 
weeks or analyzing payments for potential dupli- 
cates. The level of knowledge of the team members 
from the IT staff with respect to current applications 
will depend on the technology currently in use and 
whether the existing systems were purchased or 
developed in-house. 

Assessing the technological scope of the 
project 

* Selecting or developing an effective, quality 
financial information system is not, primarily, a 
technical decision. It is important, therefore, that 
the technology team accurately assess the extent of 
the technology impact on the project. The scope of 
this team's efforts will be directly affected by work 
that has already been done by the steering commit- 
tee, and the ongoing work of the project manage- 
ment team and the business process teams. 

The steering committee will have articulated an 
institution-wide strategy that will enable the tech- 
nology team to draw parameters around the techni- 
cal scope of the project. Reviewing these conclusions 
will provide valuable insight for the technology 
team in assessing how far the institution wants to 
push the technology window and, conversely, to 
what extent the institution intends to be more 
comfortable with proven approaches. 
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✓ Review the institution-wide strategy 

One approach to reviewing the steering 

committee's work in establishing an institution- 
wide strategy is to raise questions about leadership, 
organizational structure, and access philosophy, such 
as those listed in the sidebar to the right. If the 
steering committee has recommended taking a 
leading-edge financial system approach, it is impor- 
tant to bring the rest of the institution along with 
that position. Financial systems have a wider impact 
today than they did in the past on units outside the 
traditional financial units. Leading-edge approaches 
will probably involve imposing learning and expen- 
diture requirements on distributed users that they 
might not accept. This is why institution-wide 
consultation is important. 

As the team reviews each of the areas in the 
sidebar, it is important to assign some relative value 
or weight to each. In determining the relative value 
of technological approaches, it is often necessary to 
trade off values and constraints across these various 
areas. For example, the value of technological 
leadership and planning for the future might be 
weighed against the need to resolve some real 
business requirements issues in a timely manner. If 
those kinds of weights and priorities have already 
been specifically stated by the steering committee or 
the project management team, this certainly will 
help with the technological evaluation. However, 
where these kinds of issues have not been spelled 
out, the technology team needs to arrive at some 
sense of the relative value to the institution, and 
feed this back through the project structure for 
validation. Otherwise, much valuable time and 
energy can be mistakenly spent on resolving 
technology issues that are not germane to the work 
of the technology team. 

✓ Review project parameters 

The technology team will need to establish 
whether it has autonomy with respect to the defini- 
tion and identification of technology issues and to 
identify potential partnerships on technology issues 
with other teams. The latter can be accomplished by 
reviewing and aligning roles and responsibilities, 
identifying its reporting relationships within the 
project structure, and defining any specific reports 
or review points that may be required. 

Another significant factor is whether the project 
has encompassed a traditional needs identification 
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Technology Leadership Strategy: 

• Has a desire for the campus to be a technology 
leader been articulated as part of this project? 

• Has the strategic vision identified the institu- 
tional culture as conservative or leading-edge? 

• Is the focus on designing for the future or on 
resolving existing issues and concerns? 

IT Infrastructure Strategy: 

• Is the existing IT infrastructure and method of 
operation to remain intact? 

• Have requirements been set that the financial 
systems applications need to co-exist within the 
same or different database or technological 
environment as other core administrative 
applications? 

• Has a target information technology architec- 
ture been defined as part of the strategic vision, 
e.g., has the steering committee identified a 
specific technology strategy — migration to 
client/server, outsourcing, leveraging existing 
mainframe platform? 

• Does the strategy identify a central or decen- 
tralized model? 

Information Access Strategy: 

• How has the steering committee described the 
institutional culture or philosophy with respect 
to information access, i.e, how important is 
access to financial information? 

• Is ease of use a characteristic found in the 
conclusions of the steering committee, and how 
important is user functionality versus techno- 
logical advancement? 



approach or a business process evaluation approach. 
Where there is a need to rapidly resolve a particular 
set of issues or concerns, and where change in itself 
will create the necessary results, the technology 
evaluation team will be looking at fairly traditional 
technology responses to the business requirements, 
such as the purchase of an off-the-shelf product. 

The technology team will also need to review 
the timelines that have been established by the 
project management team. Short time frames for 
decision and implementation may represent a 
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conflict with a strategy that requires significant 
technology changes. For example, with the higher 
risks associated with such technologies as client/ 
server, the technology evaluation team may want to 
review the steering committee's recommendations 
regarding the tradeoffs between gradual and discon- 
tinuous change. Although it is more difficult to 
achieve, gradual change has the advantage that it can 
be "rolled out" on a timetable that is both techno- 
logically attainable and organizationally sustainable. 
People do not change work habits easily, so a 
gradual approach may afford the time they need to 
"ease into" the new system rather than changing 
everything overnight. Discontinuous change, on the 
other hand, has the advantage that it gets results and 
gets them faster than with the gradual approach. 
Often, the needs of the institution are such that 
large, wholesale, discontinuous change is the only 
way to achieve the goals of the project. 

Having completed all of these reviews and 
checked the results with the project management 
team, the technology team will be in a position to 
accurately estimate the scope of the technology 
portion of the task. This kind of a review process 
can significantly simplify the role of this team. The 
answers on technology requirements become more 
apparent and the technology evaluation can be 
carried out fairly easily. For example, the team may 
have learned that the project must follow existing 
standards identified by the IT organization or they 
may find there is a great deal more flexibility to 
pursue alternatives and arrive at recommendations 
to change the base for technology at the institution. 

Identifying technological alternatives 

A technology awareness-raising exercise will 
enable the technology team to place the scope of the 
project within the context of the current state of 
financial information systems technology and * 
identify possible technological alternatives. Team 
members will benefit significantly from such an 
exercise and from information on the concepts and 
language of the newer technologies. 

In some cases, the team members may lack 
current knowledge in the field, mainly because day- 
to-day work loads have precluded them from being 
involved in new technology projects. Even some of 
the IT staff on the team may require some updating 
on newer hardware, software, and development 
capabilities, for the same reasons. 



✓ Understand new technology terminology 

and concepts 

Some exposure to the technological concepts 
and language will be most valuable for the team. As 
various discussions are held, the technology lan- 
guage will become part of the day-to-day communi- 
cation between people and an awareness of alterna- 
tives will occur. Appendix B provides a glossary of 
terms with brief conceptual descriptions that can be 
distributed to the team members to promote a better 
understanding of the language and concepts. The 
appendix list is by no means exhaustive, and these 
concepts will change over time. The team may wish 
to add other items as terms are discussed as part of 
the awareness-raising activities. 

The tools available for technology solutions are 
changing constantly, so the technology team will 
need to examine emerging trends as part of its 
evaluation. Reviewing the latest trends will allow 
financial systems staff and other nontechnical 
members of the team to become more aware of the 
environment of current technology, understand its 
impact on the possibilities for business process 
improvement, and help to set out the right kinds of 
questions on the evaluation of technology relative 
to the needs of the institution. Of course, your 
institution will have to decide, based on the institu- 
tional culture, available resources, competing needs, 
and so forth, what position on the "technology 
curve" is appropriate. Some overall technology 
directions apparent at the time of this book's 
publication include the following. 

Ubiquitous use of networks. Migration to a client/ 
server environment, particularly for transaction- 
intensive processing such as is required in financial 
systems, is not moving as rapidly as many had 
assumed, but it appears that network-based manage- 
ment of data is becoming more prevalent in all 
institutional applications. The technology team will 
therefore need to evaluate the current and future 
campuswide network availability, and take into 
account the hardware, software, and management 
issues that these services present. 

Client/server developments. Particularly for many 
of the decision support systems or subsystems that 
are incorporated into financial systems develop- 
ment, a client/server environment will be viewed as 
facilitating an appropriate level of data management 
tools for each decision-maker. This does not mean 
that "the mainframe is dead"; indeed, many of the 
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servers being introduced in the new world of client/ 
server are performing the tasks of a traditional 
mainframe, relying on the client machines for very 
little transaction support. Technology team mem- 
bers will need to understand the impact of these 
new tools on current and future technology man- 
agement at their institution. 

Open systems. The movement away from propri- 
etary operating systems and databases, and toward 
an environment where moving information across 
systems and platforms will be "seamless" is likely to 
continue. Proprietary systems and databases have 
historically partitioned institutions into administra- 
tive, academic, financial, student, and development 
"camps" that did not work together effectively. 
Financial systems and information systems, in 
general, require wider participation than in the past, 
and these partitioned solutions are being reexam- 
ined. Financial systems must be increasingly avail- 
able to nontraditional users who may or may not be 
in the right proprietary camp. 

How quickly the reformatting of these propri- 
etary systems into truly open systems can take place, 
and what impact the existence of proprietary tools 
(within an open structure) will have, is not yet clear, 
but incorporating the ability to support an open 
architecture will be an important point of discus- 
sion in planning for future systems implementa- 
tions. 7 

Object-oriented technology. Object-oriented 
technology is having an impact on the development, 
enhancement, and replacement of systems, whether 
vendor-supported or homegrown. Institutions will 
likely be greatly challenged by the loss of technical 
support for the "legacy" systems that have been 
supported by traditional programmers, many of 
whom may perceive an advantage to being trained in 
object-oriented programming for their own profes- 
sional growth. 

Electronic commerce. It is now possible to reduce 
paper, reduce filing, and improve institutional 
productivity using electronic commerce. There are 



7 Two standards-based technologies emerging at the time 
of this book's publication are Open Database Communica- 
tion (ODBC) and the Open Software Foundation's Distrib- 
uted Computing Environment (DCE). Some institutions (such 
as the University of Colorado) are beginning to stipulate DCE 
compliance as a requirement for their new systems. 
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a number of important components to electronic 
commerce solutions, each of which represents 
improved business processes. In considering these 
technologies, the technology team should be sure to 
collaborate with the business process teams. 

• Electronic approval (or electronic signatures) 
can streamline internal processes within the 
institution. 

• Electronic data interchange (EDI) can be used to 
place orders for equipment, stores items, travel, 
and vehicle reservations, and is already being 
used to exchange student transcripts by several 
hundred colleges and universities. 

• "Smart-card" technology offers many advan- 
tages — procurement cards can be used to place 
small orders without prior approval, and debit 
cards can be used to automatically deposit 
student loans. 

• Electronic funds transfer (EFT) can be used to 
deposit student loan tuition payments without 
clerical involvement. Automated Clearing House 
(ACH) is a federal funds transfer technology 
that can electronically deposit or receive funds 
in the institution from students or businesses. 
ACH can replace expensive paper check transac- 
tions (that may cost as much as $35 per check) 
with inexpensive electronic transactions at a 
few cents per transaction. 

While these technologies may not be direct compo- 
nents of the financial system, the financial system 
needs to be designed in a way that encourages and 
accommodates their use. 

/ Identify "best practices " 

If an expectation for change has been estab- 
lished, the technology team will need to be exposed 
to external "best practices" to understand the 
potential for improvements in the current processes 
and systems. A key responsibility in this stage is the 
identification of other institutional experiences that 
can add value to the discussions on technological 
alternatives. Such investigation will almost certainly 
also identify potential hardware and software 
products for financial systems in the marketplace. 

Some preliminary work in this area will have 
been done by the steering committee, but it will be 
up to the technology team to investigate in more 
depth the practices already identified as well as to 
identify additional ones. There are various ways that 
this can be accomplished. The technology team can 
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consider the following suggestions and develop 
other approaches to meet the particular needs of its 
own project scope, time frame, and other factors. 

/ The team can develop relationships with other 
institutions and individuals to learn from the 
external expertise that is available. Organizations 
such as CAUSE, NACUBO, and the League for 
Innovation in the Community College will prove to 
be excellent sources of information about financial 
systems and institutions that have recently devel- 
oped or installed new systems. In many cases, 
existing documentation can be provided by those 
groups on actual or proposed installations. Several 
consulting firms also work with colleges and univer- 
sities in planning for new financial systems. 

/ Site visits to other institutions that have imple- 
mented financial systems can be arranged to provide 
peer-to-peer communication on what is installed, 
what works, and what doesn't. This needs to be a 
selective process (since there is normally a limit on 
the funds allocated for such activities) that can often 
most effectively be done in concert with the review 
of peer institutions and their business process 
changes that the business teams are conducting. 

/ Current vendors in the field can provide an 
overview of their products and services. A significant 
number of vendors provide financial systems 
applications on a variety of hardware platforms. 

Some of this information can be accumulated from 
brochures and other printed materials, through 
discussions and conversations, and by linking to 
product information available on the World Wide 
Web . 8 

Keep in mind that this consciousness-raising is 
not directly related to how vendors' products fit the 
specific needs of the institution, but more to 
identify the overall approach of vendors in using 
technology to provide products. The technology 
team should note which vendors appear to be close 
to meeting the needs of the institution, since this 
list can be used at a later stage to issue an RFI. 

A note of caution is warranted here. It is wise to 
discourage vendor visits to your institution for 
presentations or product demonstrations at this 
stage of the project, that is, before requirements 
have been fully articulated. The greatest technology- ^ 



8 See Appendix F for a list of CAUSE and NACUBO cor- 
porate members with products and/or consulting services 
related to the financial management systems area. 



related project land mine is to become prematurely 
committed to a particular solution before the review 
process has been completed or the requirements 
document prepared. The ultimate determination of 
the technology to be used will be that it can effec- 
tively support the business processes that are being 
defined by the business teams, within the strategic 
technology direction of the institution. In other 
words, the latest and greatest technology is not 
necessarily the appropriate solution to the business 
process requirements. In many cases, members of 
the technology team will be responsible for the 
implementation of the system. If they buy into a 
technology that is later not selected, the implemen- 
tation path may become much more difficult. 

Documenting existing and planned 
institutional IT infrastructure 

Team members will need to be able to deter- 
mine the institution's current and future directions 
for information technology. While institutional 
culture in general — leading edge, conservative, 
moderate — will already have been considered in 
reviewing the steering committee's work, another, 
more definable set of characteristics can provide 
further insight into institutional IT strategic direc- 
tions. That is, the team should identify and assess 
what technology choices and priorities are already 
in place, as reflected in the present infrastructure, in 
order to understand the basis for future technologi- 
cal recommendations and solutions, as reflected in 
the institutional IT plans and visions. 

/ Address infrastructure issues 

The information technology infrastructure of an 
institution can be defined as those building blocks 
that are not applications or programmatic in nature. 
In investigating these areas, the team might pursue 
some of the following questions: 

• How is the information technology division 
organized, what is the structure of IT resources, 
and what are the current relationships with 
vendors or other external partners? 

• What are the current technologies in place, for 
example: mainframe systems, open systems, 

• distributed systems, client/server systems, 

v proprietary operating systems, installed net- 

works, terminal and workstation access to 
applications and databases, installed databases, 
query languages? 





• What is the institutional strategy with regard to 
data warehouses? Will the IT organization 
provide data warehouse services or will those 
services be provided by offices such as the 
finance office? 

• Is there an open institutional architecture for 
client/server solutions either now or in the 
planning stages? 

• Do institutional and/or departmental standards 
exist with respect to the areas of security, 
access, databases, networking protocols, back- 
ups, recovery, and production operations? 

An important part of this evaluation will be 
determining the true nature of computing at your 
institution. In this evaluation, the location of the 
physical equipment, servers, or processors is not 
necessarily the issue. Centralization may be in place 
for operational issues such as system and database 
backups and maintenance, but the true method of 
operation may be distributed, particularly related to 
development, purchasing, training, and support in 
the applications areas. 

This consideration is becoming increasingly 
important as the technology provides for distribu- 
tion of responsibilities from central to distributed 
environments. The infrastructure of the institution 
comes under scrutiny to identify how these various 
development and support resources will be deployed 
for the prospective financial information systems. 
There are models that indicate that the ongoing, 
first-level support of the applications, including 
interactions with the application vendors when 
outsourced, will be done by the “owning" depart- 
ments. Implementation of new releases and interac- 
tion with the vendor's technical staff may be carried 
out through central staff with day-to-day application 
questions being directed to the help desk or re- 
sponse line of the application provider. The technol- 
ogy team can establish, and include in its profile, 
the model currently in use at the institution and use 
this in evaluating the impact of alternative system 
offerings. 

In addition to assessing the current environ- 
ment, the team should obtain the IT organization's 
strategic and operating plans and any vision or 
values statements the institution has developed for 
investment in information resources to ensure that 
future directions are taken into account. 

Strategic plans, planning principles, and vision 
statements will provide the team with the necessary 
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information about technology priorities for the 
future, preferred information architecture solutions, 
any institutional standards that are being planned 
or are currently in effect, and any other significant 
information technology priorities that may work in 
concert, or conflict, with this project. (See Appendix 
A for examples of planning principles.) 

The operating plan will provide information 
about the current focus of the information technol- 
ogy organization, which will enable the technology 
team to better plan the level of institutional tech- 
nology support that will be available for this initia- 
tive, as well as any currently existing standards or 
guidelines that should be taken into account in the 
immediate future of this effort. Having a thorough 
understanding of the already existing commitments 
of the technology organization will enable the 
technology team to make more realistic recommen- 
dations, and will give the project management team 
the necessary information for assessing how much 
of an additional burden can realistically be incorpo- 
rated, institutionally. 

Failure to understand the standards, policies, 
and procedures within the existing or planned 
technological environment will result in unneces- 
sary conflict. Policies and procedures within the IT 
organization may be less obvious than the hardware 
and software currently in use for the existing 
financial system. However, issues related to access, 
security, job scheduling, database management, 
recovery, backups, and other areas may be general- 
ized for all systems and not readily apparent in the 
specific financial systems area. 

This can also be true for functions that may be 
carried out at the department level. Some depart- 
ments may be printing their own checks or signing 
checks using hardware and software at the depart- 
ment level. Too much focus on central IT functions 
can miss these items. The team needs to be sure 
such points are not left out of the evaluation of the 
current technology environment because they will 
become significant during later stages (selection and 
implementation) of the project. 

/ Articulate development and access philosophies 

To evaluate your institution's philosophies 
concerning systems development and implementa- 
tions, the technology team might ask the following 
questions: 

• To what extent have existing applications been 
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developed in-house? Is internal development 
the standard mode of operation? If so, what 
applications development methodologies and 
tools are being used? 

• Do external vendors supply some or all of the 
administrative applications? What partnerships 
have been established between the IT organiza- 
tion and internal and external suppliers? 

• Has there been movement toward an institu- 
tional architecture to support client/server 
computing? If so, is that architecture open and 
accessible to all institutional constituents or is 
it proprietary? 

• What enhancements of services have been 
provided in recent months? 

• What is the level of internal resources available, 
in hardware, software, space, and staff? 

• Which applications or developments are driving 
the institution's technological direction? 

• Which applications and/or databases have been 
integrated to provide enterprise data? 

• Is enterprise data integration a basic approach 
to the ongoing development of new applica- 
tions? 

The team should also review current strategies 
and directions in the areas of transaction processing 
and decision support systems. Is the institution 
moving in the direction of providing more and 
easier access to data in institutional information 
systems? Are transaction processing systems being 
integrated into a common database in order to 
provide enterprise-wide access to information for 
decision-making purposes, or is the institution 
taking a data warehouse approach, reducing the 
need for transaction integration? 

Often the achievement of significant business 
process change requires an ability to integrate data 
across major applications such as student informa- 
tion systems, human resources systems, and the 
financial systems. This issue is extremely important 
in the financial area, which has traditionally focused 
on processing transactions and producing formal 
reports, but in the future will look to decision 
support capabilities to play an increasingly impor- 
tant role in the success of information systems. The 
ability to access, review, and analyze online data in 
an interactive manner will replace the existing 
procedures that require requesting a standard report 
or requesting the design and programming of a 
special report to suit the needs of the departments. 
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/ Identify technological constraints and 
opportunities 

Based on the awareness-raising that the team has 
experienced, team members next will need to 
determine any technological constraints currently 
within the IT organization. Some questions the team 
might raise include the following: 

• Is there a significant reliance on proprietary 
operating systems, inhibiting flexibility of 
platforms and potential reduction of support 
and maintenance costs? (Although these 
systems represent a sunk cost to the institution, 
which is not relevant for future decision- 
making, the existence of such systems often 
inhibits the institution's ability to think 
creatively about new solutions, and may present 
significant hurdles if the implementation of 
new solutions must be done in a way that 
integrates with existing systems for some period 
of time.) 

• What progress has been made on providing 
networked access to administrative systems to a 
broad range of faculty and staff, and what 
development is planned in this area? 

• What has been the track record of the IT 
organization in responding to the changing 
needs of the institution, internally or through 
outsourcing resources, and how prepared is the 
IT organization for working in and supporting 
new technology environments? / 

• What IT resources will be applied to the finan- 
cial information system? 

In addition to identifying constraints, the team 
will also need to articulate technological opportuni- 
ties that may have been identified within the IT 
organization. There may already be plans to migrate 
to open systems, expand network access, upgrade 
the database and query language, indicating that 
some of the constraints may already have been taken 
into consideration by the IT organization. To the 
extent that such plans are under way, the technology 
team can factor this into the evaluation of potential 
solutions to the financial systems needs. 

On the other hand, the team's awareness of the 
technological environment and current constraints 
may in effect enable it to recognize opportunities 
that may not have already been identified, and in 
fact trigger support for new directions and initia- 
tives within the IT organization. The IT organization 
and staff will obviously be most sensitive to issues 
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within their area. Open communication on these 
issues, related concerns, and possible solutions can 
bode well for the success of the financial systems 
project. 

Collaborating and validating findings 

Any review of technology will require a recipro- 
cal review of existing business processes, recogniz- 
ing that changing the business processes means 
changing the underlying support systems, as well. 
Thus, as previously suggested, the technology team 
and business process teams should work in parallel, 
reviewing the recommended process changes against 
the available technology tools, and revisiting both 
sets of information until the two visions can be 
aligned in an outcome that is appropriate to the 
institution, and supportable with the technology. 

The more iterative this process of setting 
priorities, examining available tools, and reexamin- 
ing priorities can be, the more likely it is that a 
realistic set of significant, high-priority goals will be 
achieved. This iterative review may increase the 
technological scope of the project, but alignment of 
the business process vision with the information 
technology vision for the institution is a critical 
factor for the success of the project. 

A notable project land mine to avoid is the 
attempt by the technology team to impose a techno- 
logical solution on a business process requirement. 
The potential difficulty of this land mine is not only 
project misdirection or lack of timeliness; the 
impact can be significantly counterproductive for 
people in both the business and IT areas when a set 
of false expectations infringes on the project and the 
lure of technology diverts the team from the true 
project goal of supporting business needs. 

The technology team will also need to commu- 
nicate often with the IT organization, especially if 
the strategy established in the planning phase of the 
project is toward purchasing a package or partnering 
to develop a new system. This information will form 
the basis for evaluation of the current environment 
and axomparison with other alternative technical 
approaches. It will also provide key information on 
performance-related issues that will impact the 
sizing of potential systems. In addition, the results 
of the project will require the support of the IT staff, 
and building effective communications and buy-in 
should be part of the strategy of the technology 
team. 
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While the technology team will include repre- 
sentatives from the IT organization — and probably 
have some overlap in membership with the project 
management team and steering committee — it is 
important that technology team members validate: 

(1) their interpretation of the institution- wide 
strategy for the project with the steering committee, 

(2) their understanding of the scope of the project 
with the project management team, and (3) their 
documentation of the current IT environment and 
strategic directions with the IT organization. 

In addition, the team should seek the broadest 
possible exposure and input to ensure the value and 
credibility of its conclusions. Inputs and refine- 
ments resulting from such reviews can be reflected 
in a subsequent report to the project management 
team. 

Identifying Disconnects and 
Proposing Alignments 

Having received the technology team's report, as 
well as the business process teams' reports, which 
include the appropriate technology reality informa- 
tion, the project management team will be able to 
identify possible discrepancies or disconnects 
between the strategic direction provided by the 
steering committee, feedback from the business 
process teams, and the technology team's findings 
based on analysis and review of the existing and 
potential technology infrastructure. From these 
discrepancies or disconnects, the project manage- 
ment team can develop recommendations on how to 
resolve these issues. 

The recommendations, therefore, should have 
related benefits for the project and tie back to the 
review of institutional strategies and business 
requirements. (See Table 7 for examples of the items 
that might appear.) These proposals may provide 
valuable insight in aligning the visions of the 
business area with those of the technical area and, 
ultimately, with the vision, principles, and strategies 
set forth by the steering committee to help establish 
an institutional approach to financial systems 
solutions. The relative values of these recommenda- 
tions should also be discussed and documented. 

Providing a summary of the relative values of 
new technology alternatives can provide major 
benefits in subsequent stages of the process (for 
example, in the selection process, it will be easier to 
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Table 7: Sample recommendations and related benefits 

Proposed benefit 



Recommendation 

Institute open systems architecture 
Outsource: application development 
Implement improved or integrated databases 
Expand network connections 
Develop client/server technologies 



Greater platform selection, reduced costs 
Faster response to requirements 
Improved decision support information 
More faculty access to data 
Effective platform for applications 
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decide on priorities if not all requirements can be 
met). It will make visible the deliberations of the 
technology team and provide a useful tool for 
discussion within the team and with other project 
teams. It also will provide a basis for the analysis 
and final selection from different alternatives. 

The project management team will need to 
identify the key benefits and concerns of new 
technologies reviewed during the consciousness- 
raising activities, and to relate these benefits and 
concerns to the institution's strategic directions, 
taking into account the possible impact on existing 
technologies and IT policies and procedures as well 
as the inputs from the business teams. 

This work of the project management team will 
help to redefine how the institution does business 
using technology. The objective is to get a maxi- 
mum return on the technology investment from a 
user standpoint while preserving the institution's 
standards and directions. This alignment of vision 
will be increasingly important as the project moves 
into the proposal request and evaluation stages, and 
will result in a set of recommendations that will 
move the information technology organization and 
the business organization into improved areas of 
performance and effectiveness. 

_ Creating a Requirements Document 
and Finalizing the Project Plan 

The final tasks of the project management team in 
this phase of the project are to create ( 1) a require- 
ments document that describes, at a fairly high level 
of detail, the functionality and systems needs that 
must be supported bv the technology solution, and 
includes a summary of the major strategic directions 
articulated by the steering committee, and (2) a 
revised and more detailed project scope and budget, 
building on the initial plan described in Chapter 3. 

The requirements document will be the formal 
articulation of the needs assessment that has been 



carried out by the business process and technology 
teams, incorporating recommendations from the 
business process evaluations (which will provide 
information on required and desired functionality) 
and the technology evaluation (which will provide 
information on systems requirements and prefer- 
ences). For example, the document should include: 
a description of the functionality that must be 
provided, 

a list of technical requirements that must be 
met (particular hardware platforms, databases, 
developer tools to be used, need for security 
management, client/server expectations, etc.), 
timing constraints in the implementation (e.g., 
systems that are no longer supportable require 
replacement first), 

depth and breadth of functionality (e.g., level 
of complexity in constructing the chart of 
accounts, amount of distributed activity that 
must be supported in payroll processing), 
financial constraints or considerations, and 
description of implementation support needs 
and ongoing maintenance/upgrade needs. 

The requirements document should also include 
a realistic assessment of the workforce skills avail- 
able in these areas of the institution, and an identifi- 
cation of areas where the needs assessment may be 
flawed due to lack of workforce expertise in provid- 
ing such information. It will fall to the project 
management team to incorporate its knowledge ot 
the workers involved to ensure that the needs 
assessment is accurate, and that the resulting solu- 
tion will be a reasonable and responsible system for 
the institution. A clear analysis of what resources 
the institution can provide during both the imple- 
mentation and maintenance stages will be key to the 
selection team being able to make an informed 
evaluation of the available alternatives. 

The greatest risk in this phase is to be unrealistic 
about what level of resources and skills are available 
to support the proposed change — build, buy, and 
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partner options each require differing levels of 
expertise, and differing levels of institutional 
involvement in order to be successful, so it is critical 
that there be a good fit between the final choice and 
the available expertise. 

The project manager is responsible for circulat- 
ing the requirements document to the various 
project teams for confirmation and, thereafter, to the 
steering committee for approval. Once approved, the 
requirements document will represent the blueprint 
for the solution that will be selected and imple- 
mented in the next phases of the project. 

The project scope and budget revision should 
follow the pattern of the initial project plan, now 
including the additional work that has been done on 
business process evaluation and the opportunities 
these present for institutional change; the evalua- 
tion of technology solutions and what they will 
mean for the institution's ability to introduce 
change; and a revised and enhanced resources 
estimate, based on a better understanding of what 
current staff, space, and equipment will be most 
affected by the change, and what the possible range 
of costs of the technology enhancements will be. 
Although this document cannot yet include vendor- 
specific information as to costs for purchase of 
licenses, support, and so forth, preliminary esti- 
mates of the range of such costs should also be 
prepared, in order to enhance the evaluation process 
for the RFP stage of work. 

This revised plan will need to be submitted to 
the steering committee to ensure that the evolving 
vision of priorities, needs, and available resources 
continues to fit within the broad outline of the 
steering committee's original recommendations. 
Conversely, if the additional work by the technology 
jnd business process teams has brought the project 
team to a new understanding of what the primary 
needs are, and/or what the necessary resources 
would be to meet those needs, this information 
needs to be shared with the project leaders, and the 
project as a whole will need to be reassessed before 
further work is done. 





Critical Success Factors: 

/ Balancing the technology and 

business expertise on the technology 
evaluation team 

✓ Setting appropriate boundaries in 
the process evaluations 
/ Staying connected to the steering 
committee's vision and strategies 
// Confirming the existence of technol- 
ogy tools consistent with business 
process recommendations 
/ Engaging key stakeholders in busi- 
ness process evaluations 
/ Aligning business and technology 
needs with a realistic set of require- 
ments 

/.. Ensuring that values and priorities 
are assigned to various require- 
ments to distinguish "must haves" 
in the selection process 
/- Managing the risks inherent in 
evaluating business processes 
/ Managing the user community's 
expectations of project outcomes 

Land Mines:.: 

/. Being overwhelmed by jargon and 
exercises in the process evaluations 
and losing sight of the desired 
outcomes 

/- Focusing process evaluation efforts 
on insignificant area(s) • 

/: Becoming committed to a solution 
before requirements are fully 
articulated . / , ; \ 

/_ F oilin g to understand the standards, 
policies, and. procedures within the 
existing or planned technological 
environment . > 

/ Failing to consider departmental 
practices / ; 

/; Imposing a technical solution that 
is inappropriate for business needs 
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Chapter V 
Overview 



♦' Understanding and Communicating 
the Selection Process 

Issuing a Request for Information 

Reviewing Alternative Strategies 

Appointing a Selection Team 

Issuing a Request for Proposals 

Developing an Evaluation and 
Measurement System 

♦- Presenting Recommendations to the 
Steering Committee 

Concluding Contracts with Selected 
Suppliers 



" Even in the case of an internal 
development solution, a contract should 
be considered. The implementation of a 
new financial information system is a 
crucial undertaking for your institution, 
and some level of documented 
agreement can be most useful in 
resolving potential conflicts with 
internal as well as external suppliers 






V: Selecting the Solution 



iven its substantial immersion in the 
issues surrounding the investigation of a 
new or upgraded financial information 
system, the project management team 
will have developed insight into the technology 
trends, the capability and resources of the institu- 
tion, and possible new directions that should be 
undertaken. Thus, while the project manager may 
opt to establish a selection team to develop a 
request for proposals (RFP) and evaluate proposals, 
the project management team should maintain its 
management role throughout this process, particu- 
larly in the early stages of confirming or recom- 
mending an overall strategy for buying, developing 
in-house, or partnering to develop a system. 

The project must now move from an agreed- 
upon definition of business and technical require- 
ments to a recommendation to the steering commit- 
tee for the best solution for meeting these require- 
ments. This phase will determine viable alternatives, 
eliminate alternatives based on predetermined 
measurements, identify implementation processes, 
issues, and costs, and develop documentation that 
will serve as the basis for a signed contract. 

Understanding and Communicating 
the Selection Process 

No two institutions will embark on the same 
journey and take the identical path. However, the 
process outlined here can provide a set of reliable 
and straightforward guideposts for gathering infor- 
mation, evaluating alternative proposals, and 
documenting the necessary recommendations. 

Up to this point in the project, the analysis and 
discussions have been at a conceptual or philosophi- 
cal level. During the selection stage the real impact 
on the institution will become apparent, generating 
much debate, potential project land mines, and great 
opportunities to slow the project down. 
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As in previous stages of the project, effective 
internal and external communication is a critical 
success factor. Communication with the campus 
community needs to be ongoing during the selec- 
tion process, not start with the announcement of 
the decision on project sourcing. The importance of 
keeping internal and external stakeholders informed 
during this phase cannot be overemphasized. 

The steering committee needs to have a close 
involvement with project progress and issues to deal 
with potential political implications. Department 
managers in business and technical areas need to be 
clearly versed in the direction and possible issues 
that can have an impact on staff within their depart- 
ments. The selection team needs to maintain clear 
communication with any external suppliers under 
consideration so that understanding and communi- 
cation can be managed on an ongoing basis. And 
this team needs to continually validate any assump- 
tions or measurements that will appear in the RFP 
document to ensure that the statements represent 
the work of the originating group, be it strategic, 
business process, or technological direction. 

As in previous phases of the project, effective 
communication will help to manage institution- 
wide expectations, as critical at this stage as it was in 
earlier project activities. This is especially true if a 
paradigm change is involved, such as a movement 
from internal development to purchased systems, or 
where there is an expectation of significant reengi- 
neering of business processes. Such changes have a 
direct impact on individuals, so the communication 
of factual information at every step of the way will 
reduce the potential of rumors driving the selection 
process. 

Issuing a Request for Information 

If the acquisition strategy identified in the steering 
committee's report is to develop or migrate a system 





59 





o 

ERLC 



in-house in conjunction with the internal IT organi- 
zation, the project management team will ask 
appropriate technology personnel to respond to the 
project parameters detailed in the requirements 
document. Assuming their response meets require- 
ments, there will be no need to investigate potential 
external suppliers, and the team can proceed to 
establish the measurement parameters and contract 
for an in-house development project. 

If the strategy identified in the steering 
committee's report is to purchase a product or 
consider partnering with a vendor and/or other 
institution(s) to develop a system, the requirements 
document can be used as the basis for developing a 
request for information (RFI) to be issued to poten- 
tial external suppliers. Using the RFI process will 
facilitate the collection of preliminary information 
to be evaluated by the project management team in 
determining potential products for purchase or 
potential vendor or other partnerships to build a 
new financial system. 

Essentially, issuing an RFI is a way for the 
institution to say, "Here are our needs; how would 
you address them?" The document differs from an 
RFP in that it usually is much less detailed (e.g., it 
will not include prices or timelines) and is essen- 
tially a simpler and less formal way of identifying 
suppliers who can address your needs, while simul- 
taneously culling out those who cannot. 

A good approach to take in developing the RFI is 
to use a combination of the institution's planning 
principles and business and technical strategies to 
produce a three-to-five-page list of critical, priority 
needs for suppliers to address. These should specify 
the actual institutional challenges and key func- 
tional requirements, as opposed to outlining a 
proposed solution. In other words, the RFI should 
take a "just the facts" approach, to encourage 
respondents to contribute their own key relevant 
data, eliminating the "fluff" data that can confuse 
reviewers and impede the evaluation process. 

Most of the potential external suppliers and/or 
partners should have been identified earlier in the 
project (for example, by the steering committee and 
the business process teams in their initial environ- 
mental scans and the technology team in their "best 
practices" identification process). This list should be 
reviewed to eliminate as many unrealistic alterna- 
tives as possible, given the specifications in the 
requirements document. This process is sometimes 
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described as a "knockout process," where particular 
parameters are used to eliminate one or more 
alternatives. For example, if the requirements specify 
that all administrative applications must come from 
the same vendor, any vendor that does not market a 
complete suite of applications can be eliminated 
upfront; if your specifications include client/server 
configurations, an SQL-supported relational data- 
base, a UNIX platform, or DCE-compliant technol- 
ogy, suppliers who cannot address these needs are 
also readily eliminated from further investigation. 

In terms of vendors in the marketplace, it is unlikely 
that the RFI will be issued to more than four to six 
at this point. 

The RFI process will serve as the basis for 
validating the buy-build-partner decision, while the 
RFP will serve as the basis for selecting the specific 
product or partner, as well as a guide for the delivery 
and implementation of the system. 

Reviewing Alternative Strategies 

Whether or not the work of the steering committee 
and other project teams has identified a preferred 
acquisition strategy, the project management team 
will need to review the parameters of these alterna- 
tives so that a recommendation along these lines can 
be made to the steering committee in this post- 
requirements-identification stage of the project. 

Some institutions will find a variety of possible 
alternative solutions for the specified requirements, 
and the final solution may require some intuitive 
decision-making based on a large number of inputs 
and opinions. This is not uncommon in most 
decision processes. However, the process should 
utilize objective measurements to the greatest extent 
possible. This is necessary not only to reach the best 
possible decision, but also to ensure that the process 
is perceived to be fair by all internal and external 
stakeholders. 

While variations are possible, the fundamental 
alternatives include the following: 

♦ Buy an off-the-shelf software product from a 
vendor if most requirements can be met, 
planning to work with the vendor to provide 
any missing critical functionality 

♦ Develop or migrate a system in-house with the 
internal IT organization to meet requirements 

♦ Partner with a vendor and/or other institutions 
to develop a system to meet requirements 
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Buy, Build, or Partner? 



Key considerations for a “buy" decision 

• Outdated systems creating the need for a 
"quantum" leap in functionality 

• Unstable systems or impending systems crisis 

• Insufficient staff resources to build or 
partner to build. a system from scratch and/or 
resources needed for other projects 

• Ability to adjust institutional needs and 
priorities to match available vendor solutions 

• Time frame for completing implementation 
too aggressive to be met by internal develop- 
ment 

• A need for a set of integrated administrative 
systems 

• Affordable costs for maintaining and support- 
ing purchased systems 

• • Manageable gap between campus vision and 

off-the-shelf vendor solutions 

• Good experience levels in managing vendor 
relationships 

Major advantages of this approach are (1) access 
to vendor expertise in the implementation effort 
and in providing ongoing support for users and 
ongoing enhancements to ensure technological 
currency; and (2) access to other users' solutions 
to business process problems with a widely used, 
proven product. 

Key considerations for a "build or migrate 
in-house" decision 

• Satisfaction with the functionality of existing 
systems 

• Stable legacy systems and no impending 
systems crisis 

• High-priority functionality not available in 
current or near-term future vendor offerings 

• Availability of business staff needed to 
partner with IT staff to redesign systems 

• Availability and enthusiasm of adequately 
skilled staff for assignment to the project 



• Campus technology infrastructure, architec- 
ture, and strategy in place suitable for new 
systems development 

• A clear understanding of the distribution of 
project responsibilities (project management, 
resource allocation, setting of project priori- 
ties, and so forth) 

• A method for ensuring "best practice" and a 
strategy to limit scope creep 

A major advantage of this strategy is the ability to 
provide specific functionality required and thus to 
more readily satisfy needs that will allow campus- 
driven business process changes (i.e., having it 
your way). 

Key considerations for an external "partner" 
decision 

• High-priority functionality not available in 
current or near-term future vendor offerings 

• Some development capacity on staff, but lack 
of enthusiasm for total reliance on continuing 
in-house expertise for core systems 

• Vendors and/or other institution(s) interested 
in and available to form partnerships (vendors 
willing to make a commitment, other institu- 
tions with similar high-priority needs require- 
ments who are willing to compromise/collabo- 
rate on solutions) and manageable timing and 
geographical considerations 

• Viable support structures that can be put in 
place to maintain product after implementa- 
tion 

• Feasible financing strategy 

. Appropriate degree of technical compatibility 
among institutions or technical skills of 
vendor/consultants 

A major advantage of this strategy is the ability to 
provide most of the required functionality and at 
the same time share resources and tap into the 
expertise of a wider range of professionals. 



See pages 69-73 for a discussion of additional considerations, with a focus on success factors, related to the 
alternative strategies for acquiring a financial system, especially in the post-decision, acquisition phase. 
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Note that all the possible options involve some 
kind of partnering, which in turn implies shared 
responsibilities among the partners. The decision to 
buy from a vendor or to partner with a vendor and/ 
or other institution(s) implies a partnership with 
the internal information technology organization to 
help with integration/deployment and technical 
support. The in-house development option clearly 
implies a partnership between the IT organization 
and the financial area. 

Based on responses to the functionality and 
technology requirements of the RFI, the project 
management team will decide which respondents 
should be invited for technical and end-user demon- 
strations or presentations. To help narrow the field, 
the team should request a list of customers who 
have purchased the product or used the service with 
success. Some vendors provide complete customer 
lists, but quite often this information is not sup- 
plied. It is important to identify possible peer 
institutions who are among the vendor's customers 
and make contact with them. A key question to ask 
these institutions with comparable production 
scalability is whether the system meets their expecta- 
tions. Unless your institution has the time and/or 
desire to develop a system or partner with a vendor 
to do so, you will want to choose products that are 
already running successfully at similar institutions. 

A potential land mine with regard to campus 
visits by vendors at this stage is that they are usually 
not yet dealing with costs or timelines, and thus can 
make "blue sky" presentations that can seduce an 
audience into buying into the product or service 
before the project management team can verify the 
reality of the proposed solution. If the solution does 
not check out, the team will be in the position of 
having to disenchant an already "sold" set of users. 
However, such visits can be very valuable in narrow- 
ing the possibilities and testing the reality of the 
project management's choice of alternatives. 

After campus visits have been completed and all 
information submitted has been reviewed suffi- 
ciently to get a sense of whether, and how, the 
required results will be achievable, the project 
management team will: 

(1) reevaluate priorities, especially if any high- 
priority functionality was left unaddressed by all 
respondents; 

(2) reevaluate implementation schedule/timing 
constraints, if any additional information indicates 



the current strategy may not be viable; and 

(3) refine financial projections, based on initial 
purchase/investment estimates and implementation 
costs, as well as projected operating costs (support 
and upgrade requirements). 

At this point the team should be in a position to 
confirm or question the acquisition strategy pro- 
posed by the steering committee or, if the steering 
committee has not made a recommendation in this 
area, to suggest an appropriate strategy, given the 
results of the investigation thus far. With approval 
from the steering committee to pursue the recom- 
mended alternative, it is now time to begin a more 
thorough investigation of the potential vendor 
products or partners and thus to consider appoint- 
ing a selection team to carry out the remaining 
detailed analysis tasks affiliated with these efforts. 

Appointing a Selection Team 

The project management team will be challenged to 
move briskly through this next, arduous stage of the 
project and provide quick turnaround on various 
issues that will need to be resolved. Tasks include: 

♦ issuing an RFP; 

♦ evaluating the technical content of the propos- 
als received, as well as the vendors themselves 
and their products; 

♦ recommending a specific solution to the 
steering committee; and 

♦ developing a contract with the selected supplier. 
The project management team may perform 

these tasks, or the project manager may elect to 
appoint a subset of the management team to func- 
tion as a selection team. Whatever approach is 
chosen, the composition of the selection team needs 
to include members of the project management 
team who have been engaged in aligning the busi- 
ness and technical needs into the requirements 
document, as well as at least one member of the 
steering committee who can interpret institutional 
strategic directions as outlined by that body. In 
addition to these representatives who have been 
involved with the process in previous stages, the 
project manager may wish to consider including the 
following additional representation: 

♦ A representative from the purchasing depart- 
ment or similar post, since the team will benefit 
from formal process advice as the project nears 
contract stages 
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♦ Representation from the central computing 
operations and systems areas, since many of the 
issues that will need definition will relate to 
day-to-day operations, possible development 
issues, security and utility software, and 
validation of report and performance require- 
ments 

♦ Representation from members of business 
teams that have documented specific require- 
ments for various application areas such as 
accounts payable, general ledger, payroll, and so 
forth, to evaluate written proposals or demon- 
strations of application systems 

The team should also include an individual with 
editorial and publication skills to provide support 
for developing an accurate and timely RFP docu- 
ment, which can become quite lengthy and require 
significant revision as the process continues. 

Essudimg si Requneslt ffoir Proposals 

It is important to understand the basic purposes of 
the RFP because it is usually the driving force and 
focus of the selection process. The RFP: 

♦ documents the process for responding to the 
call for proposals, 

♦ clarifies the institution's requirements to enable 
internal and/or external suppliers to better 
respond to those needs, 

♦ encourages uniformly structured responses, and 

♦ facilitates evaluation of proposals received. 

A significant coordinated work effort is required 
from all areas of the institution to achieve these 
seemingly straightforward objectives of the RFP 
document. 

The eventual contract to be signed by the 
institution and the selected supplier may incorpo- 
rate the RFP document and the supplier responses to 
that document. In this way, all of the work that has 
been expended to develop the RFP and to evaluate 
actual supplier responses can be used as the basis for 
ongoing monitoring of contract obligations of both 
parties. This also underscores the importance of 
accurate statement of requirements and careful 
documentation of supplier responses on all points in 
the RFP. 

The RFP is considered to be such a basic element 
in the evaluation of proposed systems that it is 
worthwhile to consider how the traditional RFP is 
composed. Appendix C describes a traditional form 
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of RFP for a selection process concerned with 
specifying needs, measuring the relative value of 
these needs, evaluating responses to these measured 
requirements, and negotiating contracts based on 
these results. Your institution can adapt this model 
to your situation, depending on your institutional 
culture and level of sophistication, based on the key 
elements in this description. 

Just as most RFPs are issued without containing 
any clearly stated goals and objectives for the 
performance of the desired system, i.e., what suc- 
cessful performance will look like to the user, they 
rarely contain any cost limitations either. Stating 
cost and resource limitations is interpreted as 
"tipping" the institution's hand to the supplier. It is 
recommended that cost expectations and consider- 
ations as well as human resources limitations and 
time considerations (e.g., how urgent the situation is 
with the present system) be obtained from all 
functional departments and conveyed to potential 
suppliers. Again, these should be stated in require- 
ment terms rather than as proposed solutions. 

It will probably simplify the selection team's 
task to consider the alternative of developing or 
migrating in-house systems in partnership with 
internal IT staff in the same light as external part- 
nership alternatives — the strategies and require- 
ments of the institution are the same for these 
alternate approaches. While this may seem to 
overformalize a process that involves people who 
know each other and who may in fact be members 
of the team, adopting this approach and establishing 
equal measures for each alternative will result in a 
much more informed and objective decision. Thus, 
although the RFP is usually developed primarily to 
deal with external suppliers, the process can also be 
used to validate proposals for in-house development. 

Some emerging nontraditional RFP approaches 
are also worth considering, particularly where the 
primary goal is to establish a partnership that is 
based not so much on specific measures, but in the 
alignment of vision, mission, and common agree- 
ments on the value of entering into the partnership. 
An RFP developed in this way might actually include 
less in the way of technical specifications and more 
in the way of defining the outcome expected and 
requesting the parameters of a partnership that will 
result in the desired outcome. (See Appendix D for 
sample partnership criteria used by California 
Lutheran University in a recent acquisition.) 
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What is key in this approach is the articulation 
of the parameters of the partnership itself and 
gathering information about the values and strategic 
directions of the partner. This kind of partnership 
can occur between institutions, between the user 
office and the IT development personnel within an 
institution, between a consultant and an institu- 
tion, between an institution and a supplier with a 
system product, and so forth. To enter into such a 
project will require careful analysis of the culture of 
both the institution and the intended partner(s), 
development of some measures that will identify 
how closely the partners are matched, and a method 
for identifying potential costs and time frames. 

Developing an Evaluation and 
Measurement System 

Obviously a critical issue in selecting a financial 
system solution is the accurate assessment of ven- 
dors or other potential partners. This evaluation will 
run the gamut from concrete analysis of functional 
offerings at system, subsystem, and line-item detail 
to looking at the vendor's ability to support the 
solution envisioned by the institution and its track 
record at comparable sites or installations. Appendix 
D provides an extensive list of questions the selec- 
tion team might use in the process of evaluating 
both the vendor and its products. 

Since a vendor cannot do a full-scale production 
test of the product at your institution, members of 
the selection team should make visits to sites of 
similar production scale that have successfully 
implemented the product. Extensive performance 
benchmarks should be run on every product under 
actual user conditions, if possible, before choosing a 
financial software product, because all such prod- 
ucts will have some performance limitations. 

The selection team can create detailed evalua- 
tion reports to compare suppliers based on the 
above evaluation activities. It is also helpful to 
construct a list of key benefits that would be pro- 
vided by each solution being evaluated (or ask the 
respondents to provide this for your scoring and 
use). 

The selection team can also develop an internal 
measurement and evaluation process to calculate the 
extent of the gap between your institution's identi- 
fied strategic, business, and technology needs (level 
of expectation) and the products and services 



offered by potential suppliers in their responses to 
the RFP. The evaluation is very unlikely to result in 
an exact match, even if the project is undertaken 
with the purpose of building a system from scratch 
by internal and/or external partnered resources. The 
key issue is whether the extent of the gap represents 
an acceptable solution and what efforts, between 
internal and external resources, can be brought to 
bear to minimize the gap. 

With this in mind, there are many models by 
which the evaluation of alternative proposals (and 
resulting gaps) can be measured. Your institution 
can develop its own model or modify an existing 
model to reflect the relative value of quantitative 
and qualitative factors. In general terms it is worth- 
while to consider an overall evaluation structure that 
will allow for specific evaluations of functional 
issues, provide flexibility to measure the relative 
values across applications and technical areas, and 
also allow for subjective judgments with respect to 
strategic issues and cost factors. Unless a strict cost is 
associated with the project, it may be worthwhile to 
exclude that factor from the initial stages of the 
evaluation. 

The initial evaluation should address the 
functional issues related to application requirements 
and technical requirements. These items together 
will identify a system approach that will meet your 
institution's specified needs. The business and 
technological requirements detailed in the RFP will 
offer tangible evidence of the needs for proposed 
systems to match current functional requirements 
with the future direction of the institution in the 
business reengineering or technological areas. 

The structure shown in Figure 5 was used by 
Sinclair Community College to provide an overall 
evaluation process for its integrated systems project. 
Note in this case that the weights for functional and 
technical requirements evaluation are different. This 
approach reflected a particular philosophy that 
business requirements should have a higher 
weighted value than the technical requirements. In a 
different environment, these values could be re- 
versed or both areas could receive the same value, 
depending on where an institution placed itself on 
the futuristic chart. 

Beyond the initial level of functional and 
technical requirements, the team will need to 
compare the different applications to the technical 
requirements. There is obviously more than one 
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Figure 5: 

Sample evaluation weights 
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Cost 

Evaluation 



Phase II 

Implementation 

Evaluation 



Phase I 
Functional Evaluation 




Applications 65% 




Technical 35% 



approach that can be taken to suit the needs of 
individual institutions based on strategic and 
tactical directions as well as the culture of the 
organization. Appendix E includes a detailed model 
based on the Sinclair illustration above, as well as an 
alternative model of how measures could be defined 
for use by the selection team to assist in the evalua- 
tion of proposals. A land mine associated with 
taking such an approach is that it is possible to get 
too caught up in this kind of weighted evaluation, to 
the extent of getting the right system on paper but 
not in fact. If such a device is used, it will be impor- 
tant to use a two-phase process to allow some 
reevaluation and flexibility in the weights. 

Presenting Recommendations to the 
Steering Committee 

Once negotiations within the selection team have 
been concluded and a solution has been agreed 
upon by the project management team, the project 
management team will be ready to present the 
results of the evaluation to the steering committee. 
The presentation to the steering committee should 
be similar regardless of the acquisition strategy. The 
selection team may wish to adopt the "preferred 
solution" approach, which allows making a specific 
recommendation while keeping other alternatives 
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open to the institution in the event that the final 
agreements and contracts cannot be consummated. 

The presentation to the steering committee 
should include the following key items: 

• An introduction that reviews the background to 
the project and provides a summary of the key 
findings. 

• Rationale for the new system that will recap the 
reasons that the project was undertaken. (This 
will reflect the initial steering committee report 
and the discussions on the need for improve- 
ment in the business and technology areas.) 

• Review of the overall project process involved 
in reaching the recommendation, including the 
teams of people who participated in the various 
parts of the project. 

• Review of the selection process, basically 
summarizing the steps outlined in this chapter. 
The review will include the key contents of the 
RFP, the alternative solutions considered, and 
an overview of the measurements and weights 
used to evaluate business, technology, and other 
requirements. Reference should be made to any 
reference checks, site visits, benchmarks, on-site 
demonstrations, and so on. 

• Review of benefits of the proposed system in all 
key strategic, business, and technology areas. 
Benefits for users in different departments can 
be summarized, as well as technical benefits. 

• A summary of key contract conditions, covering 
areas such as long-term commitments, hard- 
ware, system acceptance, custom programming, 
partnership arrangements, any other third-party 
software included in the plan, implementation 
support, and details on the actual implementa- 
tion plan. 

The financial considerations of the proposal can 
be dealt with in a separate section of the presenta- 
tion, identifying the costs for major areas of the 
project. Some key areas might include the following: 
/ Hardware, operating software, and other related 
equipment 

/ Application software costs by module 
/ Custom programming modifications 
/ Partnership development costs 
/ Other third-party software costs 
/ Vendor or other implementation support 
/ Project management 

/ Additional staffing during implementation (for 
example, for data conversion) 
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/ Out-of-pocket expenses 
/ Outside consultants for any part of the imple- 
mentation 

/ Computer room preparations 
/ Additional network equipment or software 
/ Printers, terminals, personal computers 
/ Other equipment such as cash registers 
/ Project contingency 
/ First-year maintenance costs 
/ Training costs prior to, during, and after 
implementation, for staff and users 
/ Costs of setting up a training facility 
/ Costs of backup and recovery during cutover 

/ Costs of running the old and new systems in 

parallel 
/ Other . . . 

The total sum of the itemized costs will be the 
proposed budget for the project. Depending on the 
extent of participation by the institution's person- 
nel, these internal costs may be identified separately 
in the cost section. 

Concluding Contracts with Selected 
Suppliers 

A good contract or partnering agreement satisfies the 
interests of both sides, is elegant in terms of best 
outcome for the most efficient and cost-effective 
effort, is legitimate and beneficial for both partners 
so neither feels compromised, and includes commit- 
ments that are well planned, realistic, and opera- 
tional. 

Contractual arrangements must be completed 
with assurance that the best possible terms for the 
institution are realized, including protection against 
vendor bankruptcy or failure to adhere to condi- 
tions. It is important that the steps of the negotia- 
tion process contain standard contracting proce- 
dures: 

/ Prepare a checklist of items to be included in 
the contract. 

/ Review and revise the supplier's standard 
contract. 

/ Review contractual arrangements with appropri- 
ate legal counsel. 

Besides these basics, successfully negotiating 
with external suppliers to go beyond standard 
performance and fit into an institutional culture — 
for example, using a team approach or total quality 
management principles — requires negotiations 
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based on satisfying mutual interests. These prin- 
ciple-based techniques 9 involve preparation that 
includes clear and complete identification of both 
parties' interests, active listening and description of 
both parties' expectations and hopes for the contract 
and partnership, a statement of problem-solving 
objectives during the negotiation and in the con- 
tract, and the forging of a lasting agreement. Articu- 
lating these expectations will be easier if the steering 
committee has developed a set of principles that 
define the desired partner behaviors and parameters 
of partnership outcomes. 

An essential item to include in the contract is 
any agreement related to performance, if perfor- 
mance is an item in the requirements and proposals. 
This can cover the anticipated volumes or transac- 
tions, users records, and other items, as well as time 
frames and procedures for conducting the perfor- 
mance tests. 

The contract will reflect the level of detail 
involved at all stages of the project. If the proposal 
to the steering committee contains all of the sug- 
gested items, the contract will reflect that level of 
detail. In some cases, as indicated in the discussion 
on RFP approaches, the contract may be much 
simpler, reflecting the intent to partner with the 
proposed supplier. Detailed contracts for this cir- 
cumstance may be generated later and at different 
phases of an ongoing project. However, at any time 
that a formal contract is being signed, the detail in 
the contract must reflect all of the agreements 
between the parties. 

Even in the case of an internal development 
solution, a contract should be considered. The 
implementation of a new financial information 
system is a crucial undertaking for the institution, 
and some level of documented agreement can be 
most useful in resolving potential conflicts with 
internal as well as external suppliers. 

Exact details of the contract will need to be 
worked out based on the typical contract document 
of the institution and with appropriate review and 
sign-off by legal and other counsel as required. 



9 W. E. Deming, Out of the Crisis (Cambridge, Mass.: MIT 
Press, 1986). 
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Critical Success Factors: 

/ Keeping the RFI simple and free 
from extraneous information 
/ Assessing accurately and objectively 
vendors and their products 
/ Getting feedback from current 
customers of products under 
consideration 

/ Ensuring that all stakeholders and 
the community in general are kept 
informed throughout the selection 
process 

/ Validating assumptions or 

measurements to include in the RFP 
/ Assessing accurately whether the gap 
between the requirements and a 
proposed solution is acceptable 
/ Regarding internal development as a 
form of partnership and formally 
treating it as such 
/. Presenting a recommendation 
within a reasonable timeframe 



Land Mines: 

/ Committing to a vendor product 
before thorough vendor and product 
evaluations can be conducted 
/ Failing to consider production 
scalability 

/ Failing to pay attention to detail in 
this highly detailed process 
/ Focusing too much on measurements 
and missing the bigger picture 
/ Failing to communicate expectations 
to the broader campus community 
during the selection process 
/ Getting "sold" on a product on the 
basis of a slick demonstration rather 
than its ability to meet 
requirements 

/- Failing to clearly articulate the 
parameters of any desired 
partnership 
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Chapter VI 
Overview 



♦ Acquiring the System 

♦ Implementing the System 

4 Conducting a Post-implementation 
Appraisal 



"No matter how good the requirements 
definition or the prototyping, the user 
will always identify unforeseen design 
criteria when implementation begins. 
This is not an indication of flawed 
design, but rather a natural process 




^plementmgth^iS^ten^ 



VI: Implementing the System 
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nee your institution has concluded a 
contract with the selected supplier, two 
project phases remain: (1) the acquisi- 
tion phase, in which the solution is 
either purchased as an off-the-shelf product or 
developed through an internal and/or external 
partnership; and (2) the implementation phase, in 
which data are converted to the new system, users 
are trained, and the institution cuts over to the new 
system. 



Acquiring the System 



The project management team will need to consider 
a number of issues that will arise for each of the 
possible strategies the institution may have chosen 
as the financial system solution. 



Considerations in developing or migrating a 
system in-house 

For whatever reasons among those listed previ- 
ously, your institution may have decided to develop 
a system in-house. As noted earlier, this solution 
actually represents a partnership between the 
information technology (IT) organization and the 
finance organization. In this case, your institution's 
information technology personnel will likely have a 
development methodology they intend to employ in 
developing a new system or migrating a current 
system to a new architecture to meet the needs 
outlined in the requirements document. 

It is not the intention of this book to cover in 
depth the issues surrounding a systems development 
project; indeed, there are many books available on 
this topic, and your institution would not have 
chosen this solution if your internal IT organization 
was not highly competent to undertake such an 
effort. There are, however, a couple of success factors 
and potential land mines to consider. 



/ Clear leadership roles 

Traditionally, the institution's technology 
department has been the dominant player in this 
kind of partnership. Most of the reasons for this are 
historical and may no longer be relevant at your 
institution. In today's more complex environment, 
however, the finance organization must play a 
leading role in any internal development project to 
ensure that the business problems will be properly 
addressed by the proposed system and that the 
project stays on target and within budget guidelines. 

A key question for the chief financial officer to 
answer is who will be held responsible for the 
success or failure of an in-house initiative? If he or 
she is the one, then complete delegation of this 
responsibility to the IT organization may be a 
questionable decision. Unquestionably, the chief 
information technology officer needs to have a 
major role, but if the accountability lies with the 
finance organization, then ultimate decision-making 
needs to lie with the CFO. An argument could even 
be made that if the CFO or his or her delegate is 
incapable of leading the project or understanding 
the technology issues sufficiently to make such 
important decisions, then the build-in-house option 
is perhaps not right for the institution. The respon- 
sibility lies with the CFO to ensure that such techno- 
logical sophistication exists in the finance organiza- 
tion before taking on such an effort. 

/ Clear project milestones with dates 

This advice might sound like motherhood and 
apple pie, but the reality is that in-house-developed 
systems are sometimes prone to delays in comple- 
tion. The reasons for this are legion. It may be scope 
creep, where the finance organization continually 
requests additional functionality in the specifica- 
tions during the development phase. It may be due 
to insufficient technology resources on the project, 
or this may be the first use of a certain technology at 
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the institution. While all of these reasons may 
appear valid to those actually involved in the 
project, the patience and indulgence of the institu- 
tion will be eroded very quickly if delays occur. 

The project management team must have clear 
milestones at key points in the project timeline, and 
the importance of meeting these cannot be over- 
stated. The experience and skill of the project 
manager (who may not be the same individual who 
has led the project through the selection phase) will 
be of paramount importance on this point. He or 
she must know how and when to compromise, and 
when to hold firm. There is a school of thought in 
the IT world that says the probability of success in a 
development project is inversely proportional to the 
duration of the project. That has serious implica- 
tions for a project that cannot keep on schedule. 

/ Importance of prototyping 

Some consideration should be given to the merit 
of pilot projects, prototyping, and using small 
group experiments to test the waters, rather than 
going for the "big bang" approach of all or nothing, 
all at once, undertaking so much that there is no 
chance to find potential problems on a smaller scale. 
It is far less risky to develop and implement at least 
one component quickly (for example, on a proto- 
type basis) and work with it to identify potential 
problems in the approach. 

For example, North Carolina State University has 
successfully used the rapid application development 
(RAD) methodology to develop several client/server 
systems through an internal Administrative Com- 
puting Services self-directed work team. This 
protoyping approach enabled the team to quickly 
develop new client/server-based systems while 
continuing to maintain legacy systems and respond 
to ongoing customer requests. 

Considerations in buying an existing vendor 
product 

Presumably, the project management team has 
evaluated the functionality of the vendor's product 
against the needs requirements documents and has 
determined that the product can be deployed either 
intact from the vendor or after some minor modifi- 
cations. In the latter case, the vendor or the central 
IT organization may do these modifications, but 
they are modifications to an existing marketed 
product and do not involve the same issues as are 



implied in a partnership with a vendor to develop a 
system from scratch. The line between the two may 
be gray in some cases, but each needs to be ad- 
dressed as a separate option, because certainly at 
their extremes they have very different critical 
success factors and land mines. 

Issues surrounding this option include: (1) 
implied process changes for the institution, (2) 
integration of the IT organization as a critical 
partner, and (3) establishment of remedy procedures 
for performance-related deficiencies. 

/ Implied process changes for the 

institution 

Probably the most critical factor involved in the 
buy option is that the campus community under- 
stands that it is likely that some processes will have 
to be changed to match those the vendor has built 
into the software. It is highly unlikely that the 
unique requirements of any institution will be 
addressed completely by an off-the-shelf product 
from a vendor. Some compromise will be required, 
and the objective of the project management team is 
to get the institution to buy into the model repre- 
sented in the vendor's product enough to relate to it 
as the "campus system." 

It is much less expensive to adapt processes to 
exploit or leverage the new system than it is to 
modify the system to fit old methods. A potential 
land mine (which can be avoided by appropriate 
communications and management of expectations) 
is that users may insist on adapting the system to 
business-as-usual, the old way of doing things, 
rather than change their own patterns. If this occurs, 
changes may have to be promoted from the top 
down; using the steering committee to communi- 
cate the importance of these changes can help to 
ensure that they will happen. It is critical to avoid 
making major modifications to a purchased system. 
In software development terms, such system modifi- 
cations — rewriting code, adding enhancements to 
existing modules, making site-specific 
customization changes, and otherwise rewriting the 
software — will significantly increase the cost, 
complexity, and duration of a system implementa- 
tion. Heavy customization can also make it difficult 
to use the vendor's upgrades as they are issued. 

Having to adapt business processes to the 
purchased system can be a positive outcome. In 
some cases, the processes built into a vendor product 




may represent "best practices" in the industry. 
Sinclair Community College is an excellent example 
of a case where the needs of the institution were 
met by minor modifications to an integrated set of 
vendor products, which enabled the college to make 
a "quantum leap" in systems functionality. In 
addition, Sinclair negotiated an agreement with the 
vendor to incorporate the customized portions of 
the systems into the product code, thus facilitating 
future product upgrades. 

The most common approach is to balance the 
costs of creating an exact fit (or the inability to get 
one) against the time or cost savings associated with 
buying from a vendor. For some smaller institutions 
with a limited technology development staff, the 
buy option may be the only viable one. In many of 
these cases, moreover, their size and organizational 
simplicity are an advantage in that there may not be 
as many conflicting parties whose diverse needs 
have to be resolved. 

/ IT function as a critical integration 

partner 

A buy option is unlikely to succeed unless the 
central IT organization has agreed to be the integra- 
tion partner that will perform the necessary tasks to 
bring in the software. Among these might be setting 
it up, testing various operational processes, working 
out backup and recovery procedures, arranging the 
interfaces with other campus systems if required, 
and establishing problem resolution procedures to 
employ when system problems occur. 

/ Performance-related deficiencies 

The institution should build remedies for 
product deficiencies into the contract with the 
vendor. These might be related to actual perfor- 
mance problems such as response times or hardware 
requirements. More serious deficiencies may relate 
to actual failure to perform the functional processes 
of the application. The reference checks with other 
customer institutions may provide valuable informa- 
tion in this case, including actual contractual 
documents and information about problems en- 
countered with the software. 

Considerations in partnering with a vendor 
to develop a system 

This has not been a very common model in the 
past, but is increasingly popular in today's higher 
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education information systems climate. One reason 
for this is that many vendors who are watching their 
older mainframe applications lose their appeal are 
feeling severe time and resource pressure as they try 
to replace them with client/server or networked 
computing models. For example, Indiana University 
recently completed the implementation of a financial 
system developed in partnership with a vendor to 
meet specific client/server needs that could not be 
met by host-based solutions. There are a couple of 
major issues related to this kind of solution. 

/ Need to share a common goal 

The likelihood of success is increased when the 
vendor feels that the fruit of the partnership is a 
product that may be sold to other institutions. 
Otherwise, the partnership is really just a service-for- 
fee arrangement. This shared-goals concept, however, 
brings with it a different set of challenges. Both 
parties must be amenable to some compromise on 
functional design. The vendor will undoubtedly be 
striving for the most flexible (generic) solution, 
while the institution will want to have its unique 
needs met. As long as there is trust and openminded- 
ness, this type of partnership can be very successful. 

/ More complicated project management 

Apart from the obvious personality-related 
problems that might accompany this kind of partner- 
ship, there is the more realistic challenge of project 
management logistics. If staff members from each 
side of the partnership are not co-located somewhere, 
the coordination logistics are likely to be daunting. A 
preferred model is to have one partner send staff to 
the other's location for the duration of the project. 

For example, Indiana sent three IT developers to 
the development site of its partner for 18 months. 
They were set up in apartments, with all utilities 
paid, and flown home to the University once a 
month. This seemingly extravagant outlay actually 
saved an inordinate amount of both out-of-pocket 
expenses and meeting time during the project. The 
two senior managers of the finance organization also 
flew out on alternate weeks to the vendor's site for 
the duration of the project to provide project man- 
agement skills and to make on-the-spot decisions on 
both technical and functional issues. Perhaps the 
most important advantage of this latter arrangement 
was to enable the University to retain an active 
leadership role in the project's management. 
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Obviously the vendor could choose to send staff 
to the campus for the project duration, but usually 
that will be a more costly choice since the vendor 
would then be charging consultant fees plus travel 
expenses, and the latter are not under the 
institution's control. Both partners might want to 
consider establishing some ground rules about 
recruitment of each other's staff during the project, 
a practice that could have very negative conse- 
quences for the project. 

Considerations in partnering with peer 
institutions to develop a system 

This option is becoming increasingly popular 
among the alternatives considered by some institu- 
tions. The emergence of object-oriented technology 
has prompted various consortia to band together to 
develop what are known as "business objects," 
packets of program code designed to perform a 
certain function. The theory is that if they can 
spread the work of developing these objects among a 
number of institutions, then all can benefit more 
quickly by assembling the objects to build the 
locally appropriate system. The Big Ten IT directors 
are exploring this possibility. 

Of course, the more traditional partnership 
involving sharing the burden of writing the entire 
system is also a possibility, although there are not 
many examples where this has been successful. 

Some pundits have said that while it may be very 
difficult to reach consensus at a given institution on 
these matters of systems design, it is impossible to 
do so across institutional boundaries! 

Some special considerations for project manage- 
ment when partnering with one or more peer 
institutions include: 

• establishing a clear understanding of responsi- 
bilities (project management, resource alloca- 
tion, setting of priorities, and so forth), 

• coming to agreement on financial liability, and 

• establishing agreement on a project plan and 
methodology for revising the plan before the 
project begins. 

The same issues noted above for in-house develop- 
ment apply here as well, with two additions. 

/ Interinstitutional legal factors 

There will probably need to be some contractual 
arrangement among the peers, and care should be 
taken not to let this step consume too much of the 




available project time. Obviously the statutory 
regulations of a state-supported institution may 
clash with those of a private one, and it would 
perhaps be wise to test these waters before going too 
far down this road. One partner may not be able to 
move as fast as another from a legal standpoint, and 
that may make the partnership difficult to manage. 

/ Ownership and support of the system 

after completion 

One of the common failures in this model is the 
erosion of support by peers after completion. Some 
institutions may opt out of the project and the 
maintenance load will have to be spread over a 
smaller group, altering the resource allocations 
accordingly. 

Considerations in partnering with both a 
vendor and peer institutions 

As the cost of developing new applications and 
the pressure to deliver them in shorter and shorter 
timeframes grows, some institutions are exploring 
other innovative ways to accomplish the job, for 
example, creating a consortium of institutions 
contracting with a vendor to develop from scratch 
or modify their existing product to the specifica- 
tions of the consortium. The advantages of this 
approach are a shared cost and perhaps a greater 
leverage on a vendor to get the work done quickly. 

Vendors do not always have an unlimited supply 
of the appropriate talent, and the possibility of 
doing custom work for, say, five or more individual 
institutions concurrently may be beyond their 
means. If, however, these colleges and universities 
can agree on a common set of specifications, then 
the vendor will get much better productivity out of 
the collective resources. 

A number of such vendor/multiple-institution 
consortia or partnerships are in the planning stages 
or under way to develop a financial information 
system. What is expected to emerge from these 
partnerships is a vendor-supported system devel- 
oped specifically for higher education that has the 
endorsement of a representative group of institu- 
tions. 

As is the case when partnering with only a 
vendor, all partners need to share a common goal 
and project management is more complicated, but 
the twist on these issues is a little different. 




/ Need to share a common goal 

If the partnership of a single institution and a 
vendor is full of challenges, consider the possibilities 
of a multiple-institution partnership with a vendor! 
Some skeptics might say that this approach is 
fraught with peril because of the difficulties of 
coordinating all the needs into the specifications of 
the system. However, the advances in technology 
and the demands placed on the institutions' CFOs to 
deliver information may motivate the partners to 
avoid bringing too many "silver bullet" items to the 
table. 

/ More complicated project management 

All the issues raised in the previous model of a 
vendor/single-institution partnership are relevant 
here to an even greater extent. One suggestion that 
has emerged is to designate one institution as the 
agent of the consortium and let its representatives 
deal with the vendor. This, of course, brings with it a 
large responsibility for the chosen leader. That 
institution must have the confidence of its partners 
and also be willing to subjugate some of its own 
institutional desires to the will of the consortium 
on occasion. For some, this may be too large a price. 
The up side of the designated agent is fairly obvious. 
The vendor cannot play different institutions against 
each other as much as might otherwise happen. For 
its part, the vendor only has to negotiate with one 
institutional partner on scope creep issues and other 
areas where decisions must be made fairly quickly 
and clearly. 

Implementing the System 

The expected outcome of the final phase of the 
financial system project is the actual implementa- 
tion of the system. The parameters of a system 
implementation process are actually unique to each 
institution. One popular way to define the comple- 
tion of an implementation is by the date on which 
the institution's general ledger is operating under 
the new system. A more general definition of an 
implementation's scope is that phase of the system 
project that begins after the computer program code 
has been acquired (whether through purchase or 
development) and extends until the system has 
begun to be used to conduct business. Hairs can be 
split as to whether the system is "implemented" after 
the first user is employing it or when the last user 
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has been brought on board, but that is a rhetorical 
issue. In fact, it is usually difficult to discern when 
the implementation is over, as implementation for 
many institutions becomes a multi-year process if 
additional functionality or new modules are being 
added to a baseline system. 

Nowhere is teamwork more important than 
during the system implementation phase of the 
project, because it is in this phase that many efforts 
begin to come together. Good documentation has to 
be in place. Training materials and resources have to 
be ready to go. The functional sponsors have to be 
ready with support staff. The technical team mem- 
bers need to really be in synch. Networks must be 
stable, code must be stress tested, and workstations 
configured, to name but a few of the technical 
elements. The project manager is in full evidence 
during implementation: every day, crises will arise 
and judgments will have to be made that affect the 
ultimate outcome. 

One land mine that arises in the implementation 
phase is the diverting of technical resources to other 
projects when the system is viewed as "finished," 
that is, acquired or developed. It is vital that comple- 
tion criteria be established so that it will be clear 
that developers and integrators need to be retained 
on the project throughout implementation. Design 
changes and fixes will inevitably arise during this 
final process, and the system will not be fully 
implemented until these are made. 

As can be seen from the tasks described below, a 
lot of the implementation work will be done before 
the final cutover to the new system occurs, but it 
would be unwise to imply that the bulk of the work 
is done at that time. If the system has been devel- 
oped in-house or as part of a partnership, there is a 
very strong likelihood of discovering bugs and 
functional deficiencies only after the system is in 
use by a significant number of users. 

The implementation process will vary depending 
on the solution your institution selects, but a 
number of tasks, described in the following sections, 
are common to all solutions in the implementation 
phase of the project. 

Assembling implementation teams 

The project management team may elect to 
create a number of special teams to manage the 
implementation process. The teams may be made up 
of the constituent members of the project manage- 
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ment team or, more likely; may also include new- 
comers to the project. Clearly individuals who have 
been key players throughout the project need to 
remain key players in the implementation or there 
will be a serious danger of discontinuity. 

Many experienced system developers and 
implementers say that a system's implementation is 
the phase where the most discipline, planning, and 
leadership is required. There are several reasons for 
this: 

• it is very difficult to back out once implementa- 
tion has actually begun, so a premium is placed 
on planning for this stage; 

• the system is now quite visible to the campus 
community and is on trial in some ways; and 

• decisions will need to be made that cannot be 
deferred for very long, placing great reliance on 
the judgment of the project management team. 

/ System integration team 

A system integration team will be necessary for 
the implementation phase of the project. If the 
system is purchased or co-developed with a vendor, 
the team should include functional, technical, and 
vendor representatives. Functional and technical 
representatives alone will constitute this team in the 
case of an in-house-developed system. Where other 
options for acquisition have been selected involving 
one or more institutional partnerships, much more 
complicated coordination will be necessary at this 
stage. Usually each institution is implementing the 
system for its own campus community, and it is 
during actual system implementation that differ- 
ences begin to emerge from institution to institu- 
tion. This is especially true if the partnership 
involved a co-development effort among the mem- 
bers of the partnership. As is the case with the 
project in general, the functional unit must take the 
lead role during implementation and arbitrate any 
problems that arise. 

The primary areas of responsibility for the 
technical members of the integration team are the 
application, network, and hardware components of 
the system. The version control of the application 
will need to be carefully managed, especially at the 
beginning. Is the application to be launched from 
the local hard drive or from a file server? With 
hundreds or perhaps thousands of potential users, 
version control of a client/server application is a 
major administrative challenge. 



/ Training team 

Almost certainly, the functionality of the new 
system will be different enough that users will need 
to be trained. Additionally, the technology used may 
bring with it the requirement for a separate training 
program aimed just at that. An example of this 
might be a switch from terminal-based systems to 
one using a graphical user interface (GUI). If the 
new system is based on client/server technology, 
there will be a considerable learning curve for both 
the technical support team (see below) and the users 
on just the hardware and software from a look-and- 
feel standpoint. 

Depending on the scale of the project, it may be 
necessary to assemble a team of trainers. At a 
minimum, a training coordinator needs to be 
identified from the functional area and, if possible, 
assigned this responsibility at the start of the 
project, perhaps even to the extent of participating 
on the project management team. There is a ten- 
dency at times to shortchange this implementation 
area by putting lower-classified personnel on this 
team. At least initially, the most knowledgeable 
functional people available should be selected for 
this training role. Key system designers are obvious 
candidates, provided they have some requisite 
training skills. This may seem wasteful at first 
glance, but most users' first contact with the system 
will be in these training sessions, and it will be vital 
to their ultimate acceptance of the system to make 
this a successful experience. The in-depth knowledge 
of the design that these key players possess will 
ensure that the inevitable difficult questions will be 
answered by those who have the best grasp of the 
system. 

After the system is stabilized, other staff can 
assume the training duties. The one caveat about 
this relates to the level of staff being trained. Users 
usually relate best to someone who is at their level 
of responsibility. This is a credibility issue as much 
as anything. 

The training team needs to work side by side 
with the documentation team described below. 

There may be some complementary possibilities 
here. Trainers will eventually have some of the best 
knowledge of the system and how the users have to 
learn it, and documentation staff will at least have 
the knowledge of the proposed functionality. There 
may well be a very blurred line between trainers and 
documentation staff, and the same people may do 
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both. One way to ensure good documentation is to 
have an instructional technology specialist write or 
review the training material. 

The training coordinator will need to handle 
training logistics such as facilities, equipment, and 
scheduling. This needs to be an individual with 
considerable initiative and resourcefulness unless 
the institution has designated a substantial budget 
for training. The training and customer service 
responsibilities are often commingled, and in fact 
doing this can foster a very effective environment. 
Obviously the knowledge and experience gained in 
each area complements the requirements of the 
other area. Staff can rotate such assignments and 
build a very effective and knowledgeable team. 

The institution needs to be prepared to estab- 
lish this team as early as possible in the project and 
leave it in place for a considerable length of time 
after implementation. New staff will need to be 
trained and existing staff will need both refresher 
courses and training on new functionality that may 
be added over time. 

/ Technical support team 

Depending on the nature of the system (espe- 
cially, for example, when making a significant 
technology change), there may be a need for a 
technical support team in addition to the primary 
functional training team and program. For example, 
in a client/server implementation, such a team will 
support the technical support personnel in the units 
more than the actual users, because there is a 
significant system configuration dimension to a 
mission-critical client/server application that the 
average user may not want to manage alone. 

In addition, central technical staff will also 
need training. The most significant land mine 
discovered by Lafayette College in a recent systems 
implementation that involved new relational data- 
base technology was not devoting more time to the 
training of computing staff in the new technology 
in advance of implementation. Their experience 
highlighted for them the importance of taking time 
prior to implementation to "train the experts to be 
experts" so that they can later concentrate on 
learning the new modules and helping users. 

If the system is vendor-developed, the vendor 
may be able to provide training and support materi- 
als for technical staff members. On the other hand, 
if it was developed in-house, there will be a greater 
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burden on technical support staff, because they will 
not have prior experience to draw upon. This is 
usually the case in mainframe-based systems, but it 
is far more significant in the case of a client/server 
application. The fundamental reason for this is that 
there are significantly more points of failure in the 
latter. Dumb terminals never needed configuration. 
There was only one version of the software operat- 
ing. The network was rarely stressed, especially if it 
was a proprietary network implementation. In a 
client/server scenario, however, every user device is 
operating the client system, even if the latter is 
served from a central server. There is also a much 
larger network burden, both in terms of traffic and 
in network complexity. All of this places a huge 
burden on the technical support team. 

/ Documentation team 

As with any complex system, documentation is a 
necessary but sometimes neglected aspect. In this 
era of electronic publishing, online help, and World 
Wide Web hypertext capabilities, there is increas- 
ingly less excuse for not providing good documenta- 
tion, and it is difficult to imagine a modern system 
being implemented without it. Training alone will 
demand it, and documentation should be seen as an 
integral part of the training process. Vendor-supplied 
systems will presumably come with documentation, 
but there may still be a need for local customization 
of these materials. If the system is developed in- 
house or in a consortium, the documentation 
demands will be enormous. They will easily con- 
sume a full-time employee for the period preceding 
implementation through complete deployment of 
the system. 

Establishing a communication process 

An effective communication process should be 
established at the outset of the implementation 
phase, as a continuation of the communication 
planning function that has been recognized as 
critical throughout the project. Such a process will 
come into even sharper focus during the project 
implementation phase. If possible, a trained commu- 
nicator, perhaps from the public relations office or a 
senior faculty member from the communications 
department, might be employed to lead this effort to 
deal with the problems of unveiling a "new system" 
with all the normal related anxieties and knee-jerk 
reactions. Keeping all parties informed along the 
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way will help to avoid the "implementation shock" 
syndrome. 

A number of technological aids are available to 
assist this process, but some of these should be used 
sparingly. For example, the electronic discussion list 
concept is a very good way to involve the users 
group, which can be both an excellent sounding 
board and a channel for communication as events 
unfold. More recently, the World Wide Web offers a 
less intrusive and in many ways a superior means of 
communication. Your institution could create a 
systems implementation Web site with various 
activities focused there such as a newsletter, a 
functionality discussion forum, a feedback vehicle, 
and a demonstration section. The University of 
Idaho found the use of such a Web site to keep users 
informed of their systems implementation to be a 
very effective communications device. 

Communication with middle and upper manag- 
ers will enhance a smooth transition to any new 
system. Although senior managers may not be daily 
users of the system, it is important to focus on the 
outcomes that will assist them in their duties. They 
must be kept informed during the process. 

The functional leadership must spend the time 
necessary to keep all stakeholders informed, and 
written or electronic communication alone will not 
work. This needs to be done in personal meetings 
with the interested parties. This is the place to 
feature the most positive proponents of the system. 
If you don't believe in it, why should they? 

It is probably not possible to do enough com- 
municating, and project teams should err on the 
side of over-communicating. Buy-in on the part of 
the users will be impossible if they are not com- 
pletely involved and informed. 

Employing appropriate management 
techniques 

Solid project management with regular meetings 
of all players is necessary at all phases of system 
projects, but perhaps is at a premium during imple- 
mentation and thereafter. How much project man- 
agement is necessary is always a dilemma: too little 
and the project is in serious jeopardy of missing 
deadlines, going over budget, or not meeting goals; 
too much and the work may never get done because 
of the overhead of feeding project management 
systems. While computerized schedule- tracking 
systems can help, they must be used with caution. 



/ Effective team leadership 

More importantly, no project management tool 
can ever be a substitute for the good judgment of 
the project leaders and key stakeholders. As in earlier 
phases of the project, good team leadership is of 
paramount importance because there will be no 
substitute for it when the project gets into trouble. 
No computerized schedule package or set of PERT 
charts will solve these problems. The team leader 
will have to know when to relax and when to hold 
firm, which boils down to good judgment. 

A key success factor in the implementation phase 
is ensuring that project leadership remains balanced 
and that roles are clearly understood by all parties 
engaged in the process. If one party (be it the 
functional, technical, or user area) is missing from 
or dominates the process, problems will almost 
assuredly follow. 

/ Implementation schedule management 

Once started, it is critical to keep momentum 
going. A long, drawn-out implementation plan, 
although seemingly safer, can in fact destroy user 
buy-in. Many practitioners suggest that the schedule 
should include a small number of well-publicized 
milestones whose dates are held firm as opposed to 
larger numbers of less significant ones that may be 
allowed to slip. The former provides a sharp focus 
for both the team members and for the stakeholders, 
while the latter diffuses the importance of a given 
milestone and may erode overall institution-wide 
confidence in the team and the project. 

Using such milestone agreements is a very 
effective and inexpensive tool. If the system is being 
implemented with an outside consultant, progress 
payments should be tied to the milestones. The same 
can be done for in-house developers if a chargeback 
process is in effect. 

Managing the implementation schedule is always 
a difficult challenge, since the project will very 
rarely go completely according to plan. For most 
institutions of any size, these projects are typically 
multi-year initiatives. It will be important in such a 
situation for the project management team to keep 
the steering committee informed of any changes in 
schedule and share the reasons for the changes. The 
ideal scenario is that the project management team 
has done a good job of building credibility during 
the early stages of the project so that the team is 
trusted when things go wrong. 
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Planning for enhancements and changes 

No matter how good the requirements defini- 
tion or the prototyping, the user will always identify 
unforeseen design criteria when implementation 
begins. This is not an indication of flawed design, 
but rather a natural process. In fact, in the era of 
client/server systems, it is almost guaranteed to 
occur. Responsiveness to these changes is key 
because the attention of the user is more focused 
now. 

If the system is an existing product supplied by 
a vendor, then the institution should have essen- 
tially adopted a policy that behavior will be adapted 
to the software. In this case, changes to the system 
are not likely. However, the newer generation of 
client/server systems offered by some vendors 
promise significant local customization, and this 
puts them in the same mold as in-house-developed 
systems. For these, there will inevitably be the need 
to deal with unforeseen changes or enhancements 
during implementation, and to have a process for 
managing these changes. 

During implementation, the system is no longer 
in the planning stages — it is actually happening! 
This is where the stakeholders really show up. Their 
requirements, priorities, and satisfaction will all 
come into very sharp focus. Misunderstandings will 
occur about perceived functionality differences: 
"This is not what I told you I needed." How the 
team handles these issues will have a significant 
bearing on how the users will accept the system in 
the long run. L.L. Bean has the right attitude here! 
Unless the suggestions seriously jeopardize the 
implementation, they need to be accommodated. If 
the schedule would be adversely affected, then the 
stakeholders need to be given a complete explana- 
tion, and the suggestion must be placed on the 
prioritized list of enhancements to be dealt with at 
the earliest opportunity. 

Some critics of the inter-institutional develop- 
ment model suggest that the implementation stage is 
the evidence for why the longer-term benefits of a 
mutually supported set of code very rarely material- 
ize. It may have been possible to keep the partners 
together through a design and even a development 
stage, but when the users at each institution begin 
to use it and demand local customization, the 
system can quickly become a unique set of program 
code that will never again be synchronized with that 
of the other partners. Hence the importance in a 
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consortial arrangement of establishing change 
control agreements. 

Cleaning up and converting existing 
system data 

Prior to data conversion, some data cleanup will 
be required. This is particularly true if the old 
system is of 1960s-1970s vintage. File-oriented 
systems did not have the cross-editing functionality 
associated with many of the newer database systems, 
so data integrity may be questionable. If any files 
have missing data for some records, that will need to 
be corrected. Any data element that is going to be a 
key field in the new system needs to be audited; the 
need to supply missing data in these cases is critical. 

A potential land mine in this effort is that it is 
possible to get so concerned with the data integrity 
that the cleanup doesn't get done. The functional 
area must do some audits of the important data files 
to be carried forward, make a judgment about when 
they are "acceptable," and proceed with caution. 

Many older systems did not have such things as 
referential integrity checks built into the databases, 
and there may be some "orphan" data in the files. 
When the new system is turned on, and referential 
integrity rules are applied, errors will almost cer- 
tainly surface. There will be a conflict here between 
the data purists and the pragmatists, and the resolu- 
tion of this issue may require some real leadership 
and judgment. Implementation could be delayed 
almost indefinitely by too strict a set of rules; a good 
compromise is to develop some system assurance 
reports that can be run after cutover in order to 
catch the errors and correct them as the system is 
being shaken down. The exception here is missing 
data in key fields; those must be corrected. 

The reason that data cleanup is necessary is that 
in most situations, it is unacceptable to implement 
the new financial system without bringing some of 
the old system data forward into it. The simplest 
reason for this is the need to be able to generate 
reports against the "old" data from both the old 
system and the new one for system commissioning 
purposes. Quite apart from the fact that the 
institution's financial office will need to feel 
comfortable with the system integrity, the auditors 
will require this before accepting the new system. A 
new system, with data from the old one correctly 
converted, should be able to reproduce reports 
equivalent to those of the old system. 
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This conversion of old data can pose a variety of 
problems. Unlike the new system ; the older system 
probably used a file or nonrelational database 
structure. This makes data modeling difficult at best; 
but if data are to be retrospectively converted; they 
must in some way be remodeled into the new 
structure. 

One way to facilitate this process is to develop a 
bulletproof set of data conversion programs for each 
legacy system whose data will be converted. This 
must be among the most thoroughly tested code in 
the entire system, because the initial data that will 
be used will have been converted by it. Those 
converted data will then become part of the new 
"historical" record of the institution and be the 
source of any audits, historical trend analyses, or 
other activities. However, the team should convert 
only as much data as will be necessary for operation 
of the system. A minimum set is one fiscal year's 
worth. Too much retrospective conversion will drain 
resources by requiring time to be spent doing 
cleanup. The campus CFO and the auditors are the 
best judge of this retrospective conversion need. 

Operating the system in parallel 

It is almost unthinkable to convert to a new 
system without some period during which both the 
new and old systems are running in parallel with 
data being fed to each. The audit issues alone will 
necessitate such a parallel operation. A tradeoff 
almost always exists between the benefits and 
security of a long parallel systems period and the 
difficulty of keeping both systems in synch. A 
minimum might be three months. 

In some ways the time period may be less 
important than the quality of the activities going on 
during the period, that is, that the players know their 
roles and responsibilities and that duplicate effort is 
not occurring. To adequately test a new system in 
parallel will take significant effort; if that is to be 
limited to a relatively short period, such as a quarter, 
then the plan must be very precise. This is not one 
of those areas where an army of people can be 
applied to get the job done in a short time. There are 
probably a limited number of people in the financial 
offices of the institution who can really validate the 
system, and their time resource must be used 
effectively. 

Another reason why this period has to be very 
carefully planned is that in some ways it is going to 



be the only phase of the effort that has an absolutely 
firm deadline. The parallel period usually ends with 
the annual closing process so that the books may be 
closed with the old system that started the fiscal 
year. It is this latter requirement that makes the 
schedule so inflexible. Most auditors will not permit 
the closing of the fiscal year on a system that was 
not the one with which the year was opened. As a 
corollary to that, usually it is not an option to 
postpone implementation a full year. So, once the 
parallel period is started, the die is cast. 

It is probably very useful to have some hardy 
"early adopters" outside the finance unit begin to 
use the system at this stage (for example, departmen- 
tal business managers). They will test the system 
better than the finance unit ever could. Their 
participation will be key during the ensuing sign-off 
process. There should be a firm schedule of what is 
to be tested in each fiscal period, and no slippage 
can be allowed in this phase. This recruiting of early 
adopters will also conserve the resources of the 
finance offices for system validation, as opposed to 
having them occupied doing transaction entry. If 
these individuals are recruited early enough in the 
process, they might also serve on one or more of the 
implementation teams. 

There cannot be enough "system assurance" 
reports during this phase. Consider testing a limited 
set of the transactions (especially those related to 
critical processes) during each period very thor- 
oughly, as opposed to testing all transactions every 
period not so thoroughly. If the source of transac- 
tions to be tested in the initial parallel period are 
controlled carefully, it will be clear what to look for 
for on the output side of the process. It is important 
to understand that output might be different 
between the old and new system, and not to assume 
that the new output is incorrect, as new systems 
may be more date sensitive than older ones. 

"Rogue" transactions that are not pre-audited 
can cause very time-consuming analysis. Remember, 
this phase of the implementation has an inflexible 
deadline, and there is no alternative to a completed 
test. It is better to completely test and validate the 
essential components of the system so that cutover 
can occur than to try to test every possible combina- 
tion of transactions and not get the basics done. 
Thus, an 80/20 rule applies here, too. Validate that 
the transactions that fall into the 80 percent cat- 
egory will go through flawlessly, and concentrate the 
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analytical time after cutover to watching the 20 
percent more carefully. 

For in-house or partner-developed systems (i.e., 
ones that have not previously been deployed else- 
where), there is the danger of a false sense of secu- 
rity on the part of the designers and developers at 
this stage, and sometimes a tendency for some team 
members to relax. Designers, developers, and other 
technical members will feel that their tasks are over 
for now and they can sit back a little — they have 
done their testing and handed over a stable, func- 
tional set of code. Few developers feel their work is 
going to be flawed and cause problems! Most seem 
to think, in the face of all the contrary evidence, that 
they have written bug-free code and all will be well. 
For reasons stated above, time is more critical 
during the parallel testing period than at any other 
phase and the developers need to be available to 
quickly make code changes. 

Conducting training for all users 

For the previous generation of mostly terminal- 
accessed, mainframe-based systems, technical 
training was often not an issue. Perhaps the users 
had accessed other terminal-based systems and so 
the interface was already familiar. Microcomputer 
and networked environments bring an entirely new 
dimension. If users are not already familiar with 
graphical user interfaces such as Macintosh or 
Windows, then the training challenges will extend 
beyond the functional areas related to the system. 
Separate sessions may be necessary just to train 
people on how to work in a mouse-driven environ- 
ment. Some institutions have gone so far as to 
mandate that users attend training before they will 
be given access privileges to the system. 

The functional training is also going to be more 
complex with networked technology, because the 
nature of the applications is different, using event- 
driven systems. In particular, navigating the myriad 
screens of a client/server system can be daunting 
unless the users have been adequately trained. 

Some suggestions for effective training include: 

/ Try to set up a semipermanent training 
facility, well equipped with the necessary hardware 
and software. This may seem like an expensive 
proposition when the proposal for the latter is 
presented, but the consequences of bad training on 
the user base will far outstrip such setup costs. For 
example, while Indiana University invested in a 
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training facility and conducted exhaustive training 
for the users, a post-implementation appraisal 
revealed a widely held view that there had not been 
enough training! Further analysis disclosed that the 
relative complexity of the client/server style transac- 
tions presented a very steep learning curve to the 
users. In retrospect, the University felt it should 
have had an even larger training site, or even 
multiple sites. This was despite an acknowledgment 
from the users that there had never been a system 
implementation with such comprehensive training 
plans. 

Parenthetically, there are very few wasted 
resources associated with these kinds of training 
facilities. After implementation, the space can be 
returned to the institution, and much of the equip- 
ment may end up being used for other purposes, so 
the cost is not a complete write-off. 

✓ As recommended earlier, appoint a full-time 
training team leader. Personnel from the prospective 
customer service organization are good candidates 
for training duties since they will inherit the post- 
implementation burdens of help-desk operation. 
They may draw on "faculty" from diverse areas to do 
the actual training sessions, but having customer 
service coordinating the effort may be a worthwhile 
investment. 

/ Provide clear and concise written material. 
Much is to be gained if individuals can answer some 
of their own questions, thereby saving the time of 
the trainers as much as possible. The class attendees 
will not retain a very large portion of the class 
content and will need to be able to refer to very 
good documentation days and weeks after the 
training event(s). It is important to have both 
electronic and printed copy of materials. The new 
users will perhaps need the latter during the initial 
training, but keeping documentation updated as 
versions change, new functionality is added, and so 
forth will prove almost impossible. Fortunately a 
number of attractive alternatives are available for 
most institutions today. The campuswide informa- 
tion system — especially if it is based on the World 
Wide Web — is a natural location for publishing and 
maintaining such materials. The hypertext-link 
features offer a functionality that never existed 
before. 

/ Conduct just-in-time GIT) training, or the 
retention of trainees will be almost zero. Even a few 
weeks between training and actual operation may be 
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too much for some users. Attendees should be able 
to go back to their offices from training and be able 
to access the system. (At Indiana University, the 
actual period while staff were at training coincided 
in some cases with the activation of their systems for 
its use. Technical staff configured their workstations 
while they were away at training for half a day.) Of 
course, support resource constraints may affect these 
decisions, but the goal needs to be JIT training! 

/ To facilitate users being able to apply what 
they have learned in class, have a practice version of 
the system available during a short period after the 
class work, but also before the actual graduation to 
production. Obviously class members cannot 
practice on the live production files, nor can they be 
expected to do very much with unrealistic test data. 
One approach is to replicate the system in a second 
server and refresh the data in it periodically so that 
they are a good approximation of the real thing. It 
goes without saying that the versions of the system 
in both practice and production servers should be 
the same. 

/ Consider getting professional help in setting 
up the training itself. Most financial accounting 
personnel are neither natural trainers nor creators of 
training materials. At Indiana, the campus training 
staff were engaged to develop the sessions and a 
professional writer was hired to do the training 
material production and system documentation. It 
proved to be a very worthwhile investment in that 
the writing quality was superior to what the regular 
finance staff could have done, and there was a 
continuity of style that proved helpful to the users. 
Wellesley College also hired a professional writer to 
do all of the documentation for its new systems. 
While a smaller institution might not immediately 
think of taking such an approach, it is even more 
important to seriously consider doing this. At a 
small college, it is likely that the same few "players" 
are already on multiple project teams. Getting some 
professional help for a task easily outsourced can be 
a very wise strategy to save staff from being 
stretched too thin. 

/ Consider the concept of a distributed 
support model across the institution. "Train the 
trainers" is a typical process in this case, where a 
champion of the system is selected from each 
departmental unit and given intensive support and 
training by the central finance unit. They then 
become the first line of support for their individual 



unit. If the resource issues associated with such a 
plan can be overcome, the benefits derived from 
increased local expertise will be dramatic. Lost time 
alone, waiting for an answer from a central unit 
help desk, will be virtually eliminated. In the first 
years of operation of a new system, that can add up 
to significant productivity savings. 

/ Evaluate general workforce skills, which will 
have a huge bearing on implementation. If the 
system features a graphical user interface and the 
workforce are all largely using character-based 
devices, there will be an additional training effort 
that is not directly associated with the system. In 
that case the central information technology organi- 
zation may offer classes in various workstation- 
related skills that can be leveraged. It may even be 
appropriate to require such "prerequisites" before 
attending the actual functional training. 

In addition, the advent of client/server systems 
places a premium on local technical support skills. 
Make sure that the technical coordinator who will 
install and support the system in the unit is well 
trained. It may even be advisable to have a separate 
"users group" for such staff where only technical 
issues are addressed. 

Establishing a functional users group 

As mentioned above, the in-house or partner- 
developed system will almost never go into produc- 
tion, completely finished, without need for enhance- 
ments or addition of other modules. The danger 
here is that every user feels that his or her enhance- 
ment request is the most important one and expec- 
tations will quickly get out of control. The develop- 
ers will not be able to effect all such changes 
immediately. A functional users group can be of 
great assistance as the body to prioritize these 
activities. 

The group should be led by a user from outside 
the finance organization. However, the latter needs 
to ensure that the group stays on course and has a 
purpose at each stage of the implementation, setting 
the agenda and the pace and ensuring that all 
potential opponents of the system are part of the 
users group. It is better to try to deal with users in 
the open forum of such a group than to have them 
taking potshots from the sidelines. 

One common suggestion is to make the most 
vocal critic the chair of such a group. Judgment will 
dictate the right course in this case, since the effect 
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of such an appointment could be either positive or 
negative, depending on the personalities involved. 

If the users group does not have a focus, it can 
be a very negative force in the implementation 
process, by serving as the lightning rod for discon- 
tent. Concentrating on "bug" or functional problem 
resolution and prioritization of enhancements is a 
proven way to maintain this focus. 

Remember, the implementation stage of the 
project is much more stressful on users than on 
technical staff. Users must deal with changed inputs, 
processes, and outputs, and many more people 
having access than in the past. 

Establishing help-desk support 

A help desk with well-trained staff is key to a 
successful implementation. If this was important in 
previous generation systems, it is vital if the system 
involves a change in both functionality and technol- 
ogy. The usual customer service function that many 
institutions have in place for an older, mature 
system may not suffice for the level of requests that 
will occur. 

The help desk needs to be able to address 
questions about both the functional and technical 
aspects of the system. It may not be necessary to 
have people who have the answers to all possible 
questions, but somewhere in the support function 
that knowledge must exist, and the help-desk 
support staff need to know where. It is very impor- 
tant that potential help-desk staff be an integral part 
of the pre-implementation process. If possible, they 
should have been members of design teams if the 
system is developed in-house. If it is a purchased 
product, they should have been on the selection 
team. Most importantly, they must be a part of the 
training process. As stated earlier, it may make sense 
to have the help-desk manager also be responsible 
for the actual training. The logistical issues alone 
associated with scheduling and setting up training 
will surely cross over to the help-desk staff. 

Another critical success factor will be the 
establishment of a "knowledge base" or problem- 
tracking database. This kind of application facilitates 
the sharing of knowledge on previously solved 
problems and will be of increasing value after 
implementation. The technology of such knowledge 
bases has improved dramatically, and the functional- 
ity of the World Wide Web is driving much of that 
change. 
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One potential land mine is staffing the help 
desk with people who do not really understand the 
"why" of the transactions or features of the system, 
but only the "how." Not only is their value in this 
kind of complex application diminished, but this 
lack of understanding can actually have a negative 
impact on the help-desk support. That is why it is 
important to have them involved up front in the 
design or acquisition. After all, the help desk is the 
point of interaction with the service provider for 
many users of the system, and their perception of it 
will depend on how well the staff performs. This 
will be especially true if the distributed support 
model is being considered, since the likely calls to 
the help desk will be from reasonably well informed 
local support staff who presumably understand the 
basic issues and are only contacting the help desk on 
difficult problems. 

Getting key stakeholder sign-off 

Assuming that the system has passed the test 
during parallel operation, there has to be a salient 
buy-in from at least some of the key players at this 
stage. The system needs to be seen as belonging to 
the institution, not to the finance organization. The 
steering committee should also formally endorse the 
widespread deployment of the system at this time. 

If there is an optimal time for the president or 
chancellor to vocally express support for the initia- 
tive, this is it. Expressions of support at any time 
from project initiation forward are welcome, but 
with all the unforeseen hurdles that will need to be 
overcome at actual implementation time, the high- 
level support at this juncture will be invaluable. 

If the representatives of a few schools or depart- 
ments have been made "early adopters," their 
endorsement should also be sought now. Have them 
participate at communication sessions, and carve 
out a real role for them in that process. 

Internal auditing can be an invaluable partner 
with their knowledge of the various possible soft 
spots and pitfalls. They should have been an integral 
and active part of the testing process and should 
sign off on the integrity of the system at the end of 
the parallel test period. 

Don't wait for everyone to sign off on the 
system. The endorsement of a smaller number of key 
players is more important than widespread consen- 
sus. 
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Cutting over to the new system alone 

With the increased dependency on technology 
an obvious task before cutting over to the new 
system is to take snapshots of data, in the event of a 
disaster and the need to go back. That is perhaps one 
of the most compelling reasons why the cutover 
takes place at fiscal year end. The snapshots have to 
be at the various levels of detail that would enable a 
recovery. At the very least, balance totals for object 
codes (income and expense classes) should be 
captured. This will probably be automatic if it is 
being done at fiscal year end. 

When the actual cutover day arrives, it is 
important to understand that for all practical 
purposes, there is no going back. The costs attendant 
on such a move are likely very high. For most 
institutions, if the cutover occurs at fiscal year end, 
a significant delay may mean a one-year delay. 
However, if the implementation plan and the parallel 
testing have been done correctly, this will be a huge 
anticlimax. No one will notice except the finance 
organization. 

The cutover to the new system can be accom- 
plished in a number of ways, but it will usually fall 
into one of two basic types — a simultaneous 
cutover of all components of the system at once, or 
a phased implementation of components. 

Full-fledged cutover at once of all components 
— transaction processing, general ledger, and 
associated components — is a very difficult proposi- 
tion for many institutions and may only be possible 
when the number of users is very limited. The 
reason for this relates to the scale of the training 
required to accomplish it. The prospect of having to 
train hundreds of users in the use of the new screens 
for transaction processing in a very short time 
makes it virtually impossible at a large institution. 
The idea of JIT training would probably be impos- 
sible with so large a number of users. The technical 
coordination and workstation configuration alone 
might prove too difficult to address. 

Having said that, there is no doubt that if it is 
possible, a onetime cutover to the entire system by 
all users has real payoffs. The benefits of the new 
system will be realized by all from day one. The 
reallocation of finance and other support staff will 
be shortened in time. The impact alone of the 
implementation being done all at one time will 
really focus the attention of the institution and 
make for a very visible beginning. 




However, numbers of users and/or their differ- 
ent levels of readiness may make it practical to phase 
in the use of the new transactions department by 
department and have the other documents sent to a 
central data entry area where well-trained staff can 
do the input until the training process is completed 
over a longer, more manageable period. This mini- 
mizes the severity levels of first-day problems for the 
finance and technical support staff. 

The general ledger poses an entirely different 
problem. It is usually not possible to manage two 
ledgers for any length of time, so the only possibil- 
ity is to cut over all data to the new G/L at one time. 
Half the institution cannot run on one set of books 
and the other half on another. 

This presents a training challenge, but one more 
manageable than the prospect of bringing the entire 
user base up on the transaction system at once. The 
problem essentially boils down to training staff on 
the use and interpretation of the new standard 
reports, and this can be accomplished by a series of 
educational sessions held over a period of no more 
than one month, usually the last month of the 
parallel operation. This gets the institution onto the 
new general ledger in one move and offers the best 
chance to bring it quickly to a stable mode of 
operation. The implementation of the transaction 
system can then proceed in an orderly manner 
dictated by training resources and organizational 
readiness. Of course, during this phase-in period, the 
central accounting functions will have to shoulder 
the data entry burden of those units not doing their 
own transaction data entry. 

It is important to remember that the only thing 
that has to happen is that at the end of the next 
fiscal period the books can be closed again. If some 
- transactions have to be entered by the accounting 
department from paper copies or "batched" in for a 
month or two, that may be acceptable. 

The greatest danger related to cutover is that 
there will be too much caution and this day will be 
postponed indefinitely. Those waiting for perfection 
will be like those waiting for Godot. Judgment is 
critical at this point. The system must be of suffi- 
cient integrity to go live, not necessarily to be 
perfect. The reason for this is that the period of 
greatest learning and adjustment will be right after 
cutover, so strive to get there as soon as possible! 

A critical success factor for in-house or partner- 
developed systems is ensuring technical competency 



mplementing the System 



at this stage of the project, more than any other. 
During the design and development phases, techni- 
cal decisions are always being made, but during 
implementation they have to be made more quickly 
and correctly. The system cannot be "down" for too 
long or the users will lose confidence in the entire 
process. This is when the technical competence of 
the developers and the judgment of the project 
leadership are at a premium. 

Conducting a Post-implementation 
Appraisal 

This process should be broken into at least two 
separate phases. The first will be simply a check that 
the system is actually operating successfully for the 
users from the outset. The help-desk staff who did 
training and implementation consulting may be best 
qualified to do this, for example through online 
surveys, questionnaires, and so forth. The second 
and more critical evaluation — performance of the 
system — may not take place for some months or 
perhaps a year after implementation. 

For users, the system must do what it is sup- 
posed to do. For management, it must not only do 
that, but it should also be completed within or close 
to budget. Many project managers seek to do post- 
implementation appraisals for "learning" purposes. 
The typical question asked is, "What would we do 
differently, if we had to do it over again?" For most 
people in the functional area, this can be a real 
waste of time. The reality is that most of them will 
not be around when such a project is repeated, and 
even if they are the rules will have changed so much 
that lessons learned may be obsolete. It may be of 
value to the technical organization, who may be 
looking ahead to another system implementation, 
But even in that case, the issues will perhaps be so 
different that the value of the experience may be 
questionable. The exception to this may be if the 
project was the first to use a new technology (such 
as client/server), a distributed data model, or per- 
haps a relational database management system. Then 
the lessons learned will be well worth documenting 
for the future. 

For the finance staff, the real appraisal that 
occurs is the next year's closing process with the 
attendant audit. The latter will be focusing on both 
the financial reports and the actual operation of the 
system from an accounting integrity perspective. 







The positive side of this auditing process is the value 
of a clean report validating the use of the system. 
Wellesley College used its external auditors to audit 
the proposed system prior to and after implementa- 
tion, so that it could report back to its governing 
board. This was different from, and in addition to, 
the auditors doing their audit of numbers and 
signing off that the new system was an appropriate 
transition from the old. In Wellesley's case, this 
system audit was actually done by the auditing 
firm's technology team, rather than by the auditors. 

Another example of post-implementation 
appraisals that may take place is an independent 
assessment by senior management of the benefits 
derived from the new system. Indiana University 
commissioned a Big Six consulting firm to do 
such an assessment a year after initial implementa- 
tion. It provided a number of significant benefits. 
The attention of the institution was focused on this 
initiative and it gave the users a real opportunity to 
air any concerns they had to an independent party. 
Such an objective evaluation can also help to focus 
on what else may need to be done to realize the full 
value of the institution's investment. Again, the 
value of getting a positive assessment is well worth 
the time and energy devoted to supporting 
such an independent appraisal. 
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t may be worth noting, in conclusion, 
that no bell is rung when implementa- 
tion is completed, since it may never be 
quite complete. Here again, the differ- 
ence may be based on whether the institution 
bought or developed a system. In the case of the 
former, the institution may or may not elect to make 
upgrades to the vendor's package by purchasing a 
maintenance contract. One reason it may not is the 
possible high cost of such a contract. If, however, the 
system was developed in-house, a continuous 
process of refinement will likely be the norm and 
the institution needs to be sure to provide the base 
funding for such efforts. 

Some experts think that the current upsurge in 
financial systems replacement is due to their neglect 
over the years as other initiatives took precedence. 
With continual changes in funding policies and 
management techniques, it may be prudent to 
ensure that campus financial systems are kept more 
in synch with such changes over the next decade. 
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I Campus-Financial Sy s temr.f or t her Futures 



Critical Success Factors: 

/ Making sure the system is seen as being 
owned by the institution, not the finance 
organization 

/ Avoiding "implementation shock" by 
keeping the community informed every 
step of the way 

/ Establishing an effective partnership with 
the IT organization, regardless of type of 
solution 

/. Establishing a clear plan, financial 

liability, and change control agreements 
in a partnership/consortium 

/ In a system development, testing the 
waters by developing in "chunks" or 
prototyping 

/ Establishing and meeting clear milestone 
dates 

/ Ensuring that key individuals remain 
involved throughout the implementation 

/ Clearly articulating where the account- 
ability for the success of the project lies 

/ Ensuring that the project leadership stays 
balanced and that roles and 
responsibilities are clearly understood 

/ Being willing to compromise when 
necessary 

/ Understanding the importance of 
just-in-time training 

/ Dealing effectively with unforeseen 
changes or enhancements 

/ -Operating the new system in parallel with 
existing systems 

/ Auditing data elements in key fields and 
supplying missing data 



✓'* Providing good technical support or 
training for technical staff 
/ Establishing completion criteria so that 
developers and integrators can be retained 
as long as needed 

/ Ensuring that technical competence is 
readily available in the cutover stage 
/ Ensuring that high-level, knowledgeable 
personnel conduct training 
/ Establishing a problem-tracking database 
/ Establishing a help desk with well-trained 
staff 

/ Using "early adopters" to test the system 

Land Mines: 

/ Allowing "scope creep" 

/ Erosion of support after project completion 
in a peer-institution partnership 
/. Diverting resources before the 
implementation is complete 
/ Bringing "silver bullets" to the table in a 
partnership with other institutions, i.e., 
requiring too much customization in a 
consortium arrangement 
/ Allowing the functional or technical area 
to dominate the implementation process 
/ Long, drawn-out implementation that 
continually misses milestone dates 
/ Getting so concerned with data integrity 
that the cleanup doesn't get done 
/ Staffing the help desk with people who 
don't understand the "why," just the "how" 
/ Exercising too much caution in cutting over 
to the new system (it doesn't need to be 
perfect) 
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VII: Conclusion 



s the authors of this book approached 
the idea of providing guidelines for 
planning and implementing campus 
financial systems, we were struck by the 
challenge of trying to address a moving target in a 
diverse and dynamic environment. There were many 
reasons not to tackle such a book, among them the 
rapidly changing — and often unproven — technol- 
ogy that institutions have available to them, and the 
complexity of not being able to prescribe definitive 
solutions for such a diverse audience from many 
types of campuses. In short, we were very concerned 
that we would be addressing an area where the rules 
seemed to change every few months and where there 
were no common solutions. 

But those concerns proved to be why we felt 
writing this book was essential. College presidents, 
business officers, information technology directors, 
and others have become overwhelmed with the 
daunting task of how to organize themselves to 
make some critical decisions about the future of 
their campus information systems. If there is a more 
complex organization for which to develop such 
systems, we would love to hear what it might be. We 
agreed that if we provided some guidance on how to 
undertake such an arduous task we would have done 
a worthwhile service for our colleagues. 

If you have taken the time to read this book, 
you have already begun a challenging journey for 
which we have not provided cookie-cutter solutions 
and single "right" answers! As authors we represent 
very different types of institutions, and it became 
clear to us that to attempt to describe a single 
answer would be unwise and unfair to our readers. 
Rather, we have attempted to describe a set of 
processes that we hope will help you begin to reveal 
your own set of answers. 

Some of the solutions you identify will be 
appropriate in the short term. Other answers will be 
applicable in the longer term. Some conclusions will 

0 




be dependant on the nature of your current invest- 
ment in legacy systems, on your motivations for 
developing a financial system, or your willingness to 
make radical changes in your business processes. But 
even with these variables, we are convinced that if 
you follow the process we have suggested in this 
book, you will come to the best conclusions about 
what is right for your institution. 

As you begin the journey towards a new finan- 
cial system, remember that the journey cannot be 
made by you alone. Your traveling companions must 
include financial and technical professionals, 
providers of information, and users of information. 

If you follow the book's advice, you will develop 
close partnerships that represent the needs and 
wisdom of these essential players in the process. 

It would not hurt to reiterate our warning about 
reviewing business processes on the campus prior to 
making decisions about your next financial system. 
Reengineering has become a tiresome buzz word to 
many, but you will do yourself a terrible disservice if 
you install a new financial system that automates 
the way you have conducted business over the last 
20 years. Colleges and universities have a nasty 
propensity to accumulate procedures, steps, and 
hierarchies over time until they find they can no 
longer afford them. It will become even more costly 
to re-tool your new financial system if you wait 
until later to change key business processes. 

Remember that the goals of your institution, 
including your business requirements, should be the 
driver of your journey. While technology and the 
marketplace will play a central role in many deci- 
sions, your institution's business needs should be 
the context for technology decisions. In the rapidly 
changing technology market, you will only help 
yourself by keeping your options open and avoiding 
painting yourself into a proprietary corner. And, 
finally, as you set off on your journey, try to keep 
your sense of humor. You will need it! 
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Appendix A: Sample Planning Principles 



Mfformatioim Tectaiology Principles, 

The Uimiversilty off Pennsylvania 

The principles below state Penn's beliefs about using 
information technology to solve business problems. There 
are 26 principles in five categories: an overarching general 
category data, applications, infrastructure, and organiza- 
tion. 

For each principle, a rationale is stated and specific 
implications listed. The principles are a link, a bridge, 
between the business people and the technologists. They 
attempt to make assumptions explicit, which helps both 
sides identify points of conflict and perhaps start resolv- 
ing them. The principles are the foundation on which the 
architectures, policies, standards, plans, and systems are 
built. They're a stable base that lets those other compo- 
nents be as flexible as they need to be. 

General 

1. University assets. 

Information technology infrastructure, business 
applications, and data must be managed as University 
assets. 

2. Functional requirements. 

University priorities and business functionality 
determine investments in administrative information 
technology. 

3. Cost-effectiveness. 

Information technology must contribute to the cost- 
effectiveness of the business functions it supports and 
must be cost-effective from the perspective of the Univer- 
sity as a whole. 

4. Policies , standards , and models. 

Policies, standards, models, and methodologies — 
based on the principles outlined here — govern the acquisi- 
tion and use of data and information technology. Regular 
update and communication are required. 



5. Investment criteria. 

Investment decisions (even those not to take action) 
must be based on business needs, cost-effectiveness, and 
consistency with standards and models. 

6. Training and support. 

Penn must put sufficient effort into ongoing support 
of its information technology assets. Skills and experiences 
from across the University must be leveraged and commu- 
nication channels opened. 

University Data 

7. Accuracy. 

University administrative data must be accurate and 
collected in a timely way. 

8. Security and confidentiality. 

University administrative data must be safe from 
harm and, when confidential, accessible only to those with 
a "need to know." 

9. Ease of access. 

University administrative data must be easy to access 
for all groups of authorized users regardless of their level 
of technical expertise. 

10. Multiple uses. 

Penn must plan for multiple uses of University admin- 
istrative data, including operations, management decision- 
making, planning, and ad hoc reporting. 

11. Purposeful collection. 

A given set of data should be collected once, from the 
source, and only if there is a business need for the data. 

12. Common base of data. 

A common base of data must be created to facilitate 
sharing, control redundancy, and satisfy retention require- 
ments. 

13. Documentation. 

Detailed information about University administrative 
data must be created, maintained, and made available. 
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Business Applications 

14. Ease of use. 

Applications must be easy to use for both novice and 
expert users. Interfaces should be similar enough to 
present a reasonably consistent "look and feel." 

15. Adaptability. 

Applications must be easily adaptable to changing 
business and technical requirements. 

16. Data sharing. 

Applications must use a common base of well defined 
University data and reference a common repository. 

17. Ensuring data quality. 

Applications must help ensure valid, consistent, and 
secure data. 

Infrastructure 

18. Common communications infrastructure. 

Academic functions and administrative systems must 

share common data, voice, and video communications 
infrastructures. 

19. Connections within the University. 

The communications infrastructure must be standard- 
ized to allow reliable, easy interaction among individuals, 
work groups, departments, schools, and centers. 

20. Connections outside the University. 

The communications infrastructure must comply with 
national and international standards that allow reliable, 
easy interaction with those communities. 

21. Hardware and software choices. 

Hardware and software for administrative use will be 
limited to a bounded set of alternatives. This applies to 
desktop computing, application servers, communications 
components, application development tools, and data 
management tools. 

22. Emerging technologies. 

Penn must devote appropriate, coordinated effort to 
evaluating and piloting emerging technologies. 

Organization 

23. Data stewards. 

Data stewards are responsible for ensuring the appro- 
priate documentation, collection, storage, and use of the 
administrative data within their purview. 



24. Process owners. 

Process owners are responsible for developing and 
maintaining the standards, structures, and business 
applications that ensure the quality and cost- 
effectiveness of specific business processes. 

25. Information Systems and Computing (ISC). 

Information Systems and Computing provides 
leadership, infrastructure, standards, services, and coordi- 
nation that permit Penn to take full advantage of its 
information technology assets. 

26. Schools and administrative centers. 

Schools and administrative centers are responsible for 
creating data and using information technology to meet 
the objectives of their organizations. 

In addition to these planning principles, Penn has devel- 
oped three architectures — information, business systems, 
and technical infrastructure — as models, or frameworks, 
from which will flow policies, standards, plans, and 
systems. The architectures themselves flow one from the 
other: 

• The information architecture includes an enterprise- 
wide data model to help Penn understand what data it 
needs. That's mapped against an enterprise-wide 
process, or activity, model that helps us understand 
what the organization is doing. Reconciling the two 
ensures that actions will be supported by the right 
data. 

• The business systems architecture lays out the compre- 
hensive set of information systems and data stores that 
are needed to carry out Penn's specific business 
processes. The systems are identified without regard 
for what's already in place or how the pie is currently 
sliced. 

• The technical architecture is a blueprint of the hard- 
ware, software, and communications components that 
will be necessary to implement the first two architec- 
tures. It's not a buy list, but a model from which 
standards and products can be derived. 

These principles are excerpted from a paper by Linda May, 
Janet Gordon, Robin Beck, and Noam Arzt, "Architecture 
and Reengineering: Partnership for Change at the Univer- 
sity of Pennsylvania," in Proceedings of the 1993 CAUSE 
Annual Conference (Boulder, Colo.: CAUSE, 1994), pp. 145- 
154. 











University ©f C©R©radl© Financial Manage- 
ment System Principles and Assnmpti©n$ 

(Excerpted from University of Colorado Financial Manage- 
ment System: Request for Proposal) 

The University of Colorado has identified eight principles 
to assist in planning for a new financial management 
application system. Included as appropriate are assump- 
tions made by CU in conjunction with development of 
these principles. These principles are subject to change 
based on further planning of the financial management 
system and general strategic direction of the University. 

Principle: Flexible Systems 

A financial management application is needed to 
support efficient, effective financial management and 
continuing business process improvement. 

Assumptions: 

• The financial management application system will 
have the flexibility required to support the above 
principle. 

• Implementation of a new financial management 
application system will bring immediate improvement 
in the University's efficiency and effectiveness. 

• The financial management application system will be 
built on a relational database management system 
(RDBMS) that will allow for additional flexibility in 
accessing data and extending the database. 

Principle: Client/server Technology 

Client/server technology is the optimum current and 
long-term application architecture for the University's 
computing. 

Assumptions: 

• Client/server technology is sufficiently developed at 
this time for the University to implement a major 
application system. 

• The University will train and equip users and technical 
staff to effectively use and support application systems 
utilizing client/server architecture. 

Principle: IT Standards 

The University will establish and support standards 
for hardware and software, development processes, and IT 
infrastructure components to promote effective, efficient 
deployment of client/server applications. 

Assumption: 

• Standards will enhance, not limit, users' ability to do 
their work by creating efficiencies, especially in the 
following areas: (1) user training, (2) technical sup- 
port, (3) systems connectivity, and (4) volume pur- 
chasing discounts. 
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Principle: Integrated Systems 

The University will use integrated application systems 
to reduce the need for reconciliation and management 
oversight as control mechansisms. 

Assumption: 

• Currently available financial management application 
systems have sufficient integration to accomplish the 
University's objectives. 

Principle: Buy Not Build 

The University will buy, not build, standard financial 
management application systems. 

Assumptions: 

• Vendors currently have client/server financial manage- 
ment application systems that are sufficiently devel- 
oped to meet core University needs. 

• Campus-funded staff (whether located at University 
Management Systems or on the campuses) will create 
and maintain campus-specific modules according to 
the University-wide system development standards. 

Principle: Match Functional and Data 

Requirements 

A major criterion in choosing a financial management 
application system is how well it meets the University's 
functional and data requirements. 

Assumption: 

• A high-level analysis of functional and data require- 
ments, coupled with vendor presentations, will 
provide sufficient information about how well an 
application system fits the University's needs. 

Principle: System Changes 

We will not change the basic code of the financial 
management system. 

Assumptions: 

• We will implement the FMS with no modification to 
the basic code because its flexibility will allow us to 
meet our essential needs without major change. 

• As we implement the new system, we will make 
sufficient modification to the business processes to 
enable effective use of the application system. 

• The system can be enhanced sufficiently to meet 
process improvement objectives through the use of 
configuration features of the application system and 
through extensions of the system using client/server 
technology (personal-computer-type software inte- 
grated with the application system). 

Principle: Data Capture 

Data is captured at its source. 
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Appendix B: Glossary of Terms and Concepts 



Analytical processing/online analytical processing 

This term was coined by relational database pioneer 
Dr. E. Codd to describe activities performed on data that 
are analytical in nature, as distinct from operational or 
transactional in nature. Analytical processing is also 
referred to as online analytical processing (OLAP), and 
operational or transaction processing is also referred to as 
online transaction processing (OLTP). Contemporary 
thinking suggests that improvements in computer system 
efficiency and functionality are achieved by separating 
analytical processing from transaction processing activi- 
ties. This is because (1) such systems use different under- 
lying technologies (hardware and software) that are 
optimized respectively for either transactions or decision 
support and analysis; (2) software tools to support 
analysis functions typically evolve faster than those that 
support transaction processing, so separating such func- 
tions allows their users to assimilate changing technology 
more cost effectively; and (3) data in transaction systems 
are frequently difficult for end users to work with and are 
rarely historical, suggesting the desirability of developing 
different data management approaches (see, for example, 
data warehouse) for the purposes of management analysis 
and reporting. A wide variety of software tools have been 
developed to support analytical processing. Such tools 
include statistical packages, spreadsheets, report genera- 
tors, graphical packages, relational databases, and multi- 
dimensional databases. 

Client/server technology 

Client/server technology represents a major milestone 
in the migration of data processing from centralized, 
host-based computing systems to distributed, networked 
computing. Client/server technology is based on a soft- 
ware partitioning paradigm in which a distributed system 
(which could also be portions of a central system) is split 
between one or more server tasks. The server is usually a 
networked computer providing service to multiple clients, 
typically desktop computers in end-user departments. 

The goal in dividing these tasks is to create a balance 



of appropriate work on both the client and server comput- 
ers, while minimizing network traffic. Client/server 
technology provides opportunities for increased flexibility 
in responding to user requirements by taking advantage of 
low-cost hardware technology, combined with network 
infrastructures and advanced application development and 
database management tools. Implementation of the client/ 
server technology may increase the responsibility of end- 
user departments for the data processing operations, 
procedures, security, recovery, and maintenance of the 
resulting systems. 

System development for client/server technology is 
more sophisticated than system development in the 
centralized or distributed computing environment. Client/ 
server is not a single technology. Its implementation will 
vary based on many design factors involving hardware, 
software, application development tools, and the sophisti- 
cation of end users and technical development organiza- 
tions. Systems development can also involve business 
process reengineering, where the application will be 
redesigned to take advantage of process improvement and 
quality management inputs. 

While client/server systems connote distribution to 
the division or department level, the design of such 
systems needs to be based on an institutional information 
architecture and infrastructure, since client/server systems 
need to coexist with other systems. The tasks that will be 
distributed to the client and server environment are the 
tasks typically contained within the traditional central 
data processing functions — presentations (screens, 
graphical user interfaces), the processes (the application 
tasks such as "compute balance" or "calculate federal 
tax"), and the database. The database, while operating in a 
particular client/server environment, needs to be available 
at the institutional level. The extent to which these tasks 
will be distributed to the server or client platforms will be 
determined by the design of the particular system. 

Current developments in the client/server arena are 
dependent on an institution's internal network structures 
and resources ("intranet"). Future developments may 






include use of external network structures and resources 
(such as the Internet) to deliver typical server functions to 
client platforms. 

Data mapping 

Data mapping is the process of aligning data elements 
in one database structure with the data elements in a 
different database structure and resolving possible con- 
flicts in the definitions and content of those elements. 

Data mapping is a significant implementation issue when 
migrating or transferring data from one database system to 
another (for example, from a nonrelational legacy system 
to a relational database system). 

Data elements in the two databases may appear to be 
the same data, but may in fact have a different meaning or 
connotation. Fields such as Cumulative GPA or Student 
Account Balance may have the same description, but 
contain different information. Resolution can involve 
review of the application code that creates the data to 
determine if the elements are the same. This issue needs to 
be dealt with in the implementation of any new system 
solutions, whether building or buying, when the new 
database structures are different from the old ones. 

Data warehouse 

Increased emphasis on information access for deci- 
sion-making purposes and the availability of low-cost, 
high-speed technology has permitted the creation of 
databases that can be used for query purposes or for 
browsing while resolving the traditional issues of impact 
on the day-to-day performance of the main systems. 

Data are extracted from the main database on a periodic 
basis and are available in the "data warehouse" for use in 
decision support and executive support systems. 

Tools that access a data warehouse are usually more 
flexible and intuitive than interfaces to legacy systems and 
thus simplify access to and retrieval of information by 
nontechnical personnel. Campus financial information 
organized by funding sources, by departments, or by 
expenditure categories are examples of data warehouse 
applications. The data warehouse may represent the total 
institutional database or may contain a subset (data mart) 
designed for use by a specific functional area. The value of 
the data warehouse is directly related to the availability 
and use of query tools. (See query languages.) 

Distributed Computing Environment (DCE) 

The Open Software Foundation (OSF), a consortium 
of major hardware and software vendors, has recognized 
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the value of building distributed computing environments 
on open standards and, toward this end, has established 
the Distributed Computing Environment (DCE). DCE 
technology is a collection of middleware services or 
"enabling technology" that can aid the deployment of 
heterogeneous, networked applications by providing for 
interoperability across heterogeneous systems. Included 
are such services as network security, user identification, 
authentication, and authorization; file services; and a 
common operating environment that allows institutions 
to share applications. According to the OSF, DCE is not 
intended to exist alone, but instead should be bundled 
into a vendor's operating system offering, or integrated in 
by a third-party vendor. DCE's security and distributed file 
system, for example, can completely replace current, non- 
network analogs. DCE is not an application, but is used to 
build applications or support purchased applications. 

Distributed systems 

Distributed systems are emerging as a result of the 
steep reduction in processor prices and the increased 
computing capability of these systems. Traditional main- 
frame, or centralized, approaches are being superseded by 
the "servers" that provide more power for less money than 
many traditional systems. Distributed systems can also 
have the connotation of "user" systems where the applica- 
tions and processes are under the control of the user 
departments. This may or may not reflect the physical 
location of the servers. In many instances, the servers are 
centrally located, in the existing operations center, to 
provide consistency of services and system backups. 

Document imaging technology 

Document imaging technology addresses the increas- 
ing concerns of institutions for the storage and retrieval of 
large databases that are often stored and retrieved as 
physical paper documents. High-speed document scanning 
equipment and the availability of high-speed processing 
and large optical storage databases have provided signifi- 
cant potential for storage and retrieval over previous paper 
files or microfilming techniques. Databases are usually 
stored on servers. Advances in programming languages 
and search techniques provide faster and more efficient 
procedures for the capture and retrieval of stored data. 

Enterprise data 

Data that span the institution — that is, data collected 
and used in support of the mission of the "enterprise" — 
are often referred to as enterprise data. Examples include 
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data in the campus general ledger, payroll system, human 
resource management systems, student information 
system, and purchasing system. Departments that capture 
enterprise data, taking responsibility for their accuracy 
and protection, are often called "data stewards, "while the 
institution is considered to be the owner of such data. 

Financial standard-setting bodies 

The phrase "generally accepted accounting principles" 
(GAAP) is a technical accounting term that encompasses 
the conventions, rules, and procedures necessary to define 
accepted accounting practice at a particular time. Several 
bodies are involved in setting standards for financial 
accounting practice. The Financial Accounting Foundation 
(FAF) was incorporated to operate exclusively for chari- 
table, educational, scientific, and literary purposes under 
Section 501(c)(3) of the Internal Revenue Code. It has 
oversight responsibility for the Financial Accounting 
Standards Board (FASB), Financial Accounting Standards 
Advisory Council (FASAC), Governmental Accounting 
Standards Board (GASB), and Governmental Accounting 
Standard Advisory Council (GASAC); selects members of 
both boards and both advisory councils; and provides 
funds for the boards. The FASB was formed in 1973 to 
establish standards of financial accounting and reporting 
for all entities other than state and local governmental 
entities, including private higher education institutions. 
The GASB was formed in 1984 to establish standards of 
financial accounting and reporting for all state and local 
governmental entities, including public higher education 
institutions. The Cost Accounting Standards Board (CASB) 
is the federal regulatory body charged with developing 
cost allocation procedures for all federal contracts. 

Information! arcMteetuare 

The way the components of an institution's informa- 
tion resources fit together — the design, planning, control, 
funding, and exploitation of those resources — can be 
described as an information architecture. The term encom- 
passes both the information itself and related aspects, such 
as the structure of how components of information relate 
to each other. Most information architectures include an 
enterprise-wide data model to help the institution under- 
stand what data are needed and how they map against 
institutional processes so that those processes can be 
supported by appropriate data. 

Information managers are responsible for the coordi- 
nation and integration of a wide range of information- 
handling activities within the organization. These include 
the formulation of corporate information policy, plans, 



standards, and design; evaluation and integration of 
effective information systems and services; the exploita- 
tion of information resources for competitive advantage; 
and the integration of internal and external information 
and data. 

Information technology architecture 

Information technology architecture describes the 
design, planning, control, funding, and exploitation of the 
investment in technology infrastructure. Over time, this 
architecture reflects advances in technology implemented 
by the institution and provides a model from which 
standards and products can be derived. Plans for use of 
these new technologies can be documented in a strategic 
planning document that identifies technologies to be used, 
policies and procedures for deployment, and the time 
frames within which these changes will occur. 

The technology infrastructure is the set of hardware, 
software, communications, cable, and personnel that 
provides, maintains, and supports access to information, 
processing of transactions, and the standards for security 
and procedures related to information technology. Typical 
infrastructure includes mainframe and server hardware 
and operating systems, applications software, campus 
network backbone and associated equipment, telecommu- 
nications equipment, and desktop computers and termi- 
nals. Infrastructure services include the design, develop- 
ment, and implementation of systems; end-user support 
and help desk facilities; and central operations services. 

As institutions migrate from central to distributed 
processing systems, the information technology architec- 
ture is modified to identify the responsibilities of the 
central or core institutional areas and the responsibilities 
within distributed areas such as colleges, divisions, and/or 
departments. The information technology architecture 
consolidates the institution's investments in technology. 
Standards established by the central group identify the 
roles and responsibilities of the distributed computing 
areas for access, data processing, operations, security, 
support, and other roles usually associated with a central 
group. With increased external access via the Internet 
(especially the World Wide Web platform), the technology 
interface between these functional areas is focusing more 
attention on security against external access or hacking. 

Integrated databases 

Integrated databases support the increased emphasis 
on access to "enterprise" data, which includes all mission- 
critical information within the institution. Access includes 
the ability to extract and produce reports as well as 
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interact in real time with the data using query languages 
to produce relevant decision support information. 

There has been significant progress towards integrated 
databases through advances in database technology, open 
systems architecture, and vendor development of applica- 
tions that integrate data used across applications such as 
payroll and student information systems. These systems 
typically contain demographic and financial information 
on faculty and students that has been difficult to bring 
together without an integrated database. 

The data do not need to reside in a single, physical 
location. However, the integrated database does need to be 
able to understand the relationships between files and data 
elements wherever they physically exist, and does need to 
eliminate, or reduce, duplicated or redundant data such as 
names and addresses and account balances. Duplicate or 
redundant data often imply duplicated data entry, which 
increases the opportunity for discrepancies to exist 
between data in different files. 

Integration of software applications based on ad- 
vanced database technology is a key concept. Most markets 
for new information technology are making integrated 
solutions a top priority, and vendors are responding to 
this demand. Some institutions are adopting a "best of 
breed" strategy of purchasing separate software modules 
from several different vendors, which makes integration of 
applications a necessary strategy. Most vendors are design- 
ing software so that their applications integrate easily with 
other vendor products. The choice of underlying database 
in a commercial product is important because it often 
limits the software that can be integrated with the finan- 
cial applications. 

Integrated databases can be created from the separate 
application databases from which they derive — for 
example, by employing "design around" strategies. This 
means that the application processes are updating the 
primary database and periodically the data are integrated 
in a separate process that allows enterprise-wide data to be 
available using a different database "engine." So, propri- 
etary operating systems with their own database support- 
ing legacy systems can be accessed to create an integrated 
set of data that can be used at the enterprise level. This is 
not necessarily an overhead, since the total processing 
time for transactions and data integration, depending on 
the size of the database, may be less with the design- 
around strategy and save large investments in the redesign 
of applications. At best, the design-around approach 
provides time for more meaningful reengineering of 
business processes without the immediate commitment to 
the technological solution. 
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Legacy systems 

Usually, but not always, this term is used to describe 
applications developed using proprietary operating 
systems and that will only run on the hardware of the 
owners of the proprietary operating system. IBM's MVS 
and Digital Equipment Corporation's VMS are examples of 
proprietary software that restrict hardware platforms of 
applications. This term may also be used to describe 
existing, installed systems which typically, but not always, 
run on proprietary systems. 

Life-cycle budgeting/ costing 

This concept developed originally in the architecture 
and engineering disciplines to embody the total capital 
and operating costs of an investment in plant over a 
planned span of use. Life-cycle costing is particularly 
important in the context of technology acquisition and/or 
development activities owing to the relatively short life 
span of much hardware and software. A frequent and key 
"land mine" in many technology development projects is 
the failure of the project team and steering group to look 
beyond the basic purchase (or development) cost of 
hardware and software. In a life-cycle costing environ- 
ment, these costs would be assessed, as would the ongoing 
costs of supporting the technical environment, including: 
hardware and network utilization costs; software acquisi- 
tion, development, licensing, and maintenance costs; and 
training, help-desk, and other support costs. Increasingly, 
utility costs can play a major role in life-cycle costs of 
major information systems. In particular, thorough life- 
cycle costing exercises are critical where host-based 
systems are to be replaced with client/server systems. 
Planners must also account for the "opportunity costs" 
associated with reducing the utilization of the campus 
host computer in cases where hardware leases or purchases 
make it difficult or costly to downsize this hardware. 

Middleware 

Middleware refers to the software that mediates 
between an application program and a network. It man- 
ages the interaction between disparate applications across 
the heterogeneous computing platforms. (See Distributed 
Computing Environment.) 

Networked environment 

Many systems developments are taking place within 
networked environments. The networks tie together the 
central (proprietary or open) systems with distributed 
processing servers and user workstations through a 
campus backbone of cable. In a higher education environ- 
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ment, these networks often serve student workstations in 
the labs from servers located in central or distributed 
environments. Networks underscore the critical issues 
related to expanded access to information for faculty, staff, 
and students with a need to know. In the traditional data 
processing environment, information was considered to be 
departmental, and access was restricted to very few people. 
With the increased recognition of the knowledge worker 
and the need to share information, the focus is on expand- 
ing access to many more people. As the tools for the 
remote office continue to develop, access from off-campus 
locations will continue to grow, via standard telephone 
communications or other more effective means. 

Object-oriented programming and design 

The basic concept in this approach is that of an 
"object" which is a data structure (abstract data 
type) encapsulated with a set of routines, called "meth- 
ods," that operate on the data. Operations on the 
data can only be performed via these methods, which are 
common to all objects that are instances of a particular 
"class." Thus the interface to objects is well defined, and 
allows the code implementing the methods to be changed 
so long as the interface remains the same. Object-oriented 
design is one of the stages of object-oriented program- 
ming. It is a method in which a system is modeled as a 
collection of cooperating objects, and individual objects 
are treated as instances of a class within a class hierarchy. 

Opera systems 

These are systems that are built around open operat- 
ing systems that are supported on multiple-vendor plat- 
forms. UNIX is the primary example of this technology. 
Although it may come in many flavors, such as IBM's AIX 
or Digital's VX, the basic operating system is supported on 
various hardware platforms. Several software vendors in 
the education arena provide applications software that is 
supported on various vendor platforms — IBM, Digital, 
Hewlett-Packard, Sun, and so forth. In this case, the 
application vendors take care of any idiosyncrasies in the 
various flavors of the UNIX operating system. 

Performance measurements 

Performance measurements are a set of qualitative and 
quantitative metrics that identify key indicators (critical 
success factors) on which a system will be judged and 
selected. Performance criteria reflect the business and 
technical requirements and can include the application 
functionality required, the speed and response time of the 
system, the technology base preferred, and the support, 
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training, and implementation needs of the institution. 

The ability to reach an objective judgment will be en- 
hanced by documented selection criteria that focus on key 
areas and identify the relative priority of the various 
criteria. 

Query languages 

Query languages are the tools that allow users to 
access meaningful sets of data in an interactive manner, 
independent of predefined reports produced by standard 
operations processes. As the importance of the informa- 
tion database becomes more critical to the success of the 
enterprise, so does the capability of a query language to 
locate, extract, and combine data into meaningful infor- 
mation for decision-making or avoidance of risk. Query 
languages typically are developed for a specific database, 
and the efficiency of the database engine and the query 
language need to be considered together. 

Relational databases 

A relational database is a database based on the 
relational model developed by E.F. Codd. A relational 
database allows the definition of data structures, storage 
and retrieval operations, and integrity constraints. In such 
a database, the data and relations between them are 
organized in tables. A table is a collection of records, and 
each record in a table contains the same fields. 

Certain fields may be designated as keys, which 
means that searches for specific values of that field will 
use indexing to speed them up. Records in different tables 
may be linked if they have the same value in one particu- 
lar field in each table. Oracle and Sybase are well-known 
examples of relational databases products. 

Responsibility center management 

This resource allocation and financial accountability 
model has gained currency in several major U.S. research 
universities in the past 15 years. In this model, a univer- 
sity school, college, or major business unit is designated a 
responsibility center and is responsible for meeting 
negotiated net revenue objectives. Revenue is recognized 
from all sources such as direct and indirect sponsored 
research revenues, gifts and endowment income, and 
tuition and fees. Many universities using responsibility 
center management allocate the full costs of operations to 
the centers, including costs for space utilization, utilities, 
and even land. The theory of responsibility center man- 
agement is that focusing the attention of revenue center 
managers (deans, directors) on net revenues creates 
behaviors that are both revenue-seeking and efficiency- 
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seeking in cases where centers that generate surplus net 
revenues are allowed to retain the surplus. Deans, direc- 
tors, and other revenue center managers who generate 
surplus net revenues are able, thus, to finance program 
growth. In units where revenues are insufficient to meet 
program costs, campus subventions and subsidies are 
made explicit. Such accounting makes it possible for 
campus leaders to make informed decisions about the 
economics of different academic programs and to grow or 
shrink such programs accordingly, in concert with other 
(non-economic) campus objectives. 

Security systems and backup 

Security systems and backup provide a set of stan- 
dards, policies, and procedures designed to protect and 
restore the information assets of the institution and 
include appropriate physical control and security access of 
the hardware, software, databases, and processes, and the 
recovery procedures for partial or complete loss of these 
resources. Continuous availability and security of informa- 
tion, appropriate and timely backups, and disaster recov- 
ery plans need to be an integral part of the design, imple- 
mentation, and maintenance of an information system. 

In a central mainframe environment where the 
computers, programs, data files, and processes are cen- 
trally maintained, policies and procedures ensure recovery 
for various conditions ranging from the need to restore a 
file to more significant disaster situations. 

In the networked environment, security systems and 
back up become much more complex. In a distributed 
computing environment, programs, data file updates, and 
application processes may be occurring anywhere on the 
physical network. There are dependencies on connections, 
cables, and intermediary servers to process transactions or 
respond to requests for information. 

Increased access to integrated databases requires 
processes and procedures to ensure authorized access to 
information. Access to the network can take place any- 
where, depending upon the capabilities of the network 
and communications systems. So security systems need to 
be designed into layers that allow validated access to the 
network and continuing validation of a person's right to 
navigate and access the information system. As the access 
to information becomes more important, so too does the 
ability to access the data on a 24-hour basis. 

Shadow systems 

Shadow systems are locally developed systems that 
duplicate and/or improve on functions or activities 
supported by core institutional information systems. 
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Because many core systems are old, use antiquated and 
unfriendly technology, and were not designed to support 
analysis and ad hoc reporting, and as campus desktop 
computing environments have matured, many departmen- 
tal personnel who depend on financial information have 
deployed sophisticated systems to provide departmental 
accounting and other services. These systems can essen- 
tially represent duplicate accounting books. While these 
systems go far in meeting local needs for information and 
function, they often generate substantial redundant 
workload and create often-significant data integrity and 
quality problems resulting in complicated month-end and 
year-end reconciliations with the institution's "book of 
record." Financial information systems that meet the 
needs of the most particular and sophisticated users of 
such information — often the auxiliaries — reduce the 
incentives to develop and support shadow systems. 

Smart-card technology 

A smart card refers to any plastic card (like a credit 
card) with an embedded integrated circuit for storing 
information. Smart cards are being incorporated into 
soldiers' dog-tags and used to store hospital patients' 
medical records. They are also being used as student/ 
faculty/staff campus ID cards that can contain information 
on that individual. Other uses are as a form of token in a 
financial system; for example, the system can store on the 
card electronic money or credits towards campus food 
services. Some campuses are beginning to use these cards 
to store personnel information or for security access. 

World Wide Web 

The World Wide Web (WWW) refers to the universe of 
hypertext servers (HTTP servers) that allow text, graphics, 
sound files, etc. to be mixed together and accessed via the 
Internet. The Web often points to the whole constellation 
of resources that can be accessed using tools such as 
Gopher, FTP, HTTP, Telnet, and Usenet. Many colleges and 
universities are beginning to use the Web as a front end 
(or interface) to their administrative systems, especially for 
students to access their information in legacy systems. 
Many institutions also use the Web for institutional 
forms, replacing traditional paper forms. For some institu- 
tions, using a Web platform is a good strategy for migrat- 
ing legacy systems into a networked environment. 



Some descriptions in this glossary were adapted from definitions 
found in The Free On-line Dictionary of Computing (http://wombat.doc. 
ic.ac.uk/foldoc/contents.html). 
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Appendix C: Components of a 

Traditional RFP 



Sections I - Gemeiral taffcDiriBialtnam 

Introduction 

The introduction should state the basic objectives of 
the RFP (as identified on page 63), identify the confiden- 
tial nature of the RFP as a valuable document of the 
institution containing information pertinent to its opera- 
tions, and provide an overview of the remaining sections 
to orient prospective suppliers. 

Schedule of Key Events 

This subsection highlights major activities associated 
with the issue of the RFP: proposal dates, site visits or 
demonstrations, contract awards, and implementation 
objectives. This provides valuable information for suppli- 
ers in responding to the schedule and resource require- 
ments of the bid. Schedules will obviously be subject to 
change at the discretion of the institution. 

Response Terms and Conditions 

This subsection provides information to suppliers to 
identify the formal procedure surrounding the RFP 
process. It may include how vendors should provide notice 
of intent to bid, the date and location for delivery of 
proposals, and the process of requesting clarification on 
any item included in the RFP. This allows the institution 
to control the process internally by providing defined 
contacts for the suppliers. This process may include 
identifying that the requests for clarification and the 
subsequent response will be copied to all suppliers, thus 
keeping them all apprised of information. 

This subsection may also provide some basic defini- 
tions that will protect the institution: 

• Rules for bidders' conferences 

• Right to amend or supplement the information 

• Hold-harmless clauses 

• Evaluation period 

• Price changes 

• Assignment or subcontracting 

• Payment schedule 
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* Insurance 

* Award of contract (official approval process and 

notification) 

* News releases and confidentiality 

To some extent these may be considered as "boiler plate" 
items that can be lifted from standard contracts. The 
institution's legal counsel should review these to ensure 
the institution is not at risk. 

Vendor Eligibility and Selection Criteria 

This subsection is designed to allow the institution to 
eliminate potential suppliers who do not meet specific 
requirements of the project and/or to allow a potential 
supplier to decide not to bid. This is extremely valuable to 
the selection team since it can significantly reduce the 
number of alternatives that need to be taken into consid- 
eration throughout the process. 

The information will outline the institution's expecta- 
tions, which may be related to the supplier's experience in 
the marketplace, installations at comparable sites (for 
example, community colleges or research universities), 
installations at sites with comparable volumes (number of 
students, faculty, total staff, general ledger accounts), 
availability of systems that integrate, as an example, 
student information systems and financial information 
systems, and systems with specific technical architecture 
(e.g., client/server technology or rapid application devel- 
opment tools). These kinds of criteria will obviously vary 
from institution to institution, and can be identified as 
"knock out" criteria. This concept, which tends to facili- 
tate the progress of the evaluation team, was discussed on 
page 60. 

The eligibility criteria may focus on primary eligibility 
criteria and general evaluation criteria. The primary 
eligibility criteria tend to be highly visible items that will 
become quickly apparent and tend to eliminate alterna- 
tives at an early stage. The general evaluation criteria 
identify items that will probably be evaluated as part of 
the proposal and evaluation process. It would include 
items such as overall ability to meet requirements, 




supplier's financial health and stability, ability to meet 
data conversion needs, compliance with standard audit 
control procedures, quality of site visits, and characteris- 
tics of proposed hardware and software. The presentation 
of these criteria in this subsection will tend to make 
potential suppliers think through the process and deter- 
mine if they want to bid on the project. 

Section II - The Institution and 
Information Technology 

The purpose of this section is to indicate to suppliers the 
importance of an effective ongoing relationship with the 
institution in achieving its information technology goals 
and objectives. These characteristics can involve short- 
term and long-term objectives and indicate the need for 
the supplier to be in a continual development mode with 
its products and services. 

Overview of the Institution 

This subsection provides historical and environmental 
data about the institution to the suppliers. The informa- 
tion could include the mission of the institution, the 
governance, size and location, initiatives that are indica- 
tive of the institution's administrative and academic 
directions and challenges, and an organization chart of the 
major areas of the institution. 

Strategic Direction of Technology 

This subsection is tailored to the strategic vision of the 
institution and points out to the supplier the information 
that the institution believes is important to allow the 
supplier to share and participate in that vision. It will 
provide information to support the strategic statements in 
the steering committee's strategic directions report. 

Typical of the content of this section would be: 

• The mission-critical nature of excellence in informa- 
tion systems and technologies. 

• Strategies related to the internal system development 
philosophy of the institution. This will indicate to 
suppliers the role that the in-house resources of the 
institution may play in the project. This information 
will provide insight into the extent to which the 
institution is looking at buy, build, or partner solu- 
tions. 

• The strategy surrounding the transition to a new 
financial information system, including a description 
of the technology infrastructure to support the 
business process required by the institution, the 
transaction processing orientation of the system, and 







the institution's need for supplier support resources 
for technical and user staff in the planning, project 
management, training, testing, and installation of the 
required business applications. The information may 
also indicate the needed supplier support for the 
conversion of databases and the skill development of 
the institution's technical and user staff. This area is 
obviously projecting into the implementation and 
identifying the levels of support, training, and docu- 
mentation that will be expected from the supplier. 

• The future technology direction of the institution. 
This will be described to indicate that the institution 
needs to have ongoing enhancement to the system. 
These areas could include the kinds of future technol- 
ogy described in the technology evaluation discussion 
and would emphasize those areas related to access, 
graphical user interfaces, decision support systems, 
client/server architecture, and other areas of new 
technology which the institution wishes to pursue. 

• Strategic issues related to cost/benefit considerations 
where the institution will describe its focus on cost/ 
benefit issues and the added value of new and en- 
hanced system. This discussion can include insight 
into the institution's concept of partnering with the 
supplier using internal staff to encourage new develop- 
ment and maintain costs. The supplier's input on 
improved productivity of existing staff resources can 
also be covered in this area. 

Description of existing technological environment 

This subsection provides suppliers with information 
on the existing technology environment of the institu- 
tion. This could include such information as: 

Existing administrative computing services — purpose of 
the department, organization, staffing, and location. The 
capability of the existing staff to deal with issues con- 
tained in the strategic section and in current projects and 
workload can be identified. 

Existing application systems — description of the major 
applications currently in production, basic modules of 
each application, and any specific functions that may not 
be standard in the industry, including leading-edge tech- 
nologies already in operation. 

Existing hardware and software systems — a detailed 
description of production and development hardware and 
operating software, number of workstations, terminals, 
printers, and other devices in the central environment, 
including: 

• major operating software, programming languages, 
and report generation capability; 
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• networking capabilities (including network applica- 
tions), servers, and types of wiring and communica- 
tions cabling; 

• user department workstations, terminals, and printers, 
including distributed applications if applicable; and 

• other technology information that may be useful to 
the supplier in responding to the short-term and long- 
term needs of the institution. 

Section m - Business Process Requirements 

This section describes the application requirements of the 
institution. These requirements can be presented in 
subsections that cover General Application Requirements 
and Specific Application Requirements. 

General Application Requirements 

This subsection describes the function and feature 
requirements that are common to all the application 
software modules as well as those system-level functions 
that will be used by the user community. 

These requirements describe key features that are 
deemed to be critical to the institution's user community. 
They tend to indicate the infrastructure of applications and 
common threads upon which the system should operate. 

To some extent, this information will indicate the extent to 
which application modules are integrated into a compre- 
hensive business system. 

In general, this subsection allows the business process 
and technology teams to identify what they consider to be 
critical items without repeating the items in each specific 
application requirement. These issues will normally be 
generated as a result of developing requirements and 
participating in consciousness-raising activities with 
various suppliers and other institutions. While the issues 
will be tailored by the individual institution, the following 
may give some indications on the content of this subsec- 
tion; 

• Outside agencies that have validated one or more parts 
of the system for accuracy and consistency with 
industry standards 

• Maintenance agreements 

• Support plan for customers 

• Indicators of an integrated system — common database 
and nonduplicated data elements, security, screens, 
automatic updating of financial records from student 
registration or payroll transactions 

• Optional features that may be turned on and off and 
which may affect performance 

• Backup, recovery, and transaction-logging features 



* Documentation/online documentation available to 
users 

* Ability to navigate between applications without 
lengthy sign-on procedures 

* Support for network facilities such as uploading and 
downloading of files to and from workstations 

* Archiving and retrieval of archived data 

* Remote printing capability/report generation capabili- 
ties 

* Support for future applications not described in the 
Specific Application Requirements: inventory manage- 
ment, smart card, Internet/Web access, equipment 
tracking, facilities management 

* Customization performed for and by other customers 
that could be available 

Specific Application Requirements 

This subsection describes the function and feature 
requirements of the user community for all specific 
applications. This is the section that the suppliers may be 
required to copy, complete, and return to the institution; 
it is the most specific, detailed section of the RFR 

This subsection results from documentation on the 
features and functions, which may be classified as essen- 
tial or desirable. This indicates to the supplier the relative 
importance of each line item. The scoring on these items 
may allow the supplier to respond in different ways to the 
line items. One technique that can be used in an RFP 
allows for the following responses by suppliers: 

A. Feature or function currently exists and can be 
demonstrated 

B. Feature or function exists, but must be modified prior 
to implementation to meet specific requirements 

C. Not currently available, but will be provided prior to 
implementation at no extra charge 

D. Not currently available, but will be provided prior to 
scheduled implementation at an additional cost 
identified in the cost section 

E. Feature or function not included in proposal 

The responses in this format will quickly identify the 
"gap" between customer expectation and supplier product 
capability. The gap list can be used to identify potential 
custom development, internal development, or partnering 
strategies. 

In the typical financial information system document, 
a sample Specific Application sheet could appear as shown 
on the following page. The major point of this or other 
methods of presenting requirements is to provide a 
detailed list of business application requirements while 
providing flexibility between essential and desirable as 




General Ledger System 

1. The system should support multiple agencies 

2. Ability to accommodate different fiscal years for different accounts 

3. Automatically summarize inter-fund debit and credit transactions to a summary 
transaction when the debit and credit transactions occur within the same account 

4. Ability to initiate budget transfers online 



A B C D [E] 
A B C D [E] 

A B C D [E] 
A B C [D] E 



well as flexibility in the suppliers' responses. This section 
is a comprehensive section since it will contain all the 
detail on all the business processes covered by the project. 

Secti<n>ini IV - Other Meqmiremeimts 

This section describes the technical requirements and 
requests specific information (which will include cost 
information) in technical and support areas. 

Implementation and Support Requirements 

This subsection describes requirements for supplier 
deliverables for implementation of the proposed system 
and would include items such as the following: 

• Detailed implementation work plan and progress 
reporting system 

• Overall direction for software loading and file conver- 
sions 

• Establishment of production and test systems 

• Provision of formal training on each module for users 
consistent with the implementation schedule 

• On-site assistance and telephone assistance 

• Post-implementation support to fine tune the system 

System Level Software and Technical Requirements 

This subsection requests information on a variety of 
topics related to implementation and the overall system 
capability: 

• System security — covers security levels, password 
implementation and maintenance, special features for 
standard profiles, handling of unauthorized attempts 
to access the system, levels of security 

• Database management — describes data access meth- 
ods, tools and report generators available, any file or 
data limits, maintenance requirements, and database 
recovery capabilities 



• Query/report writer — requests information on 
formatting, data access, real-time report generation 
from the database, ability to project query run times, 
ability to extract and download, user friendliness 

• Application development tools — identifies functions, 
features, benefits, and training requirements of 
available software development tools 

• Connectivity — describes support for one or more 
network communication disciplines, remote termi- 
nals, and printers 

• Teleprocessing, operating systems, and system utilities 
required for production operations — includes job 
scheduling, peripheral management system 

Hardware Requirements 

This subsection requests specific information on 
hardware proposals. The focus in this section is to ensure 
the capacity of the system and the performance of the 
system. The information provided in various sections of 
the RFP has identified the volume of transactions across 
applications, the number of users, and the configuration 
of terminals and workstations. The supplier needs to 
respond with a hardware configuration that will support 
these stated volumes. This subsection will also address 
some of the more pragmatic production operation issues 
in terms of print volume, magnetic tape backup and 
recovery capability, and the ability to monitor perfor- 
mance and fine tune the system. 

SecttMDim ¥ - Proposal F<orimnai1t arnnd 1 

This section is designed to manage the response to the RFP 
and provide specific instructions on how suppliers need to 
respond, including any standard forms to be used. The 
sequence of this section mirrors the layout of the RFP. 



Outline of Proposal Format 

This subsection outlines the format and can include: 

Notice of intent to bid 

• Cover letter 

• Supplier statement of ability to meet primary eligibil- 
ity criteria 

• Supplier financial data 

Proposed solution 

• Table of contents 

• Transmittal letter 

• Total system solution 

• Supplier qualifications 

• Application software requirements 

• System-level software and technical requirements 

• Hardware requirements 

• Proposed implementation schedule and level of effort 

• Any additional information 

• Exceptions to the RFP (supplier identifies specific areas 
where they are unable to meet one or more areas of 
the RFP) 

• Sample contracts 
Cost proposal 

This is a separate section that allows the supplier to 
provide the cost information separate from the system 
proposal information. 



Sample documentation 

This could include samples of supplier documentation for 
users, operators, data entry, technical staff, plus any 
additional material that will identify the availability and 
quality of the documentation. 

Description of Proposal Sections 

This subsection provides detailed information on each 
of the steps summarized in the outline above. 

Standard Forms for Responses 

This subsection provides standard forms that will 
provide a consistent method for all suppliers' responses, 
and makes comparison more straightforward. Forms 
included in the package should reflect the content of the 
RFP, so that suppliers can be led through the responses to 
each section. Separate forms can be provided for the 
suppliers to identify cost information so that the func- 
tional responses can be reviewed and evaluated separately 
from the cost information. If required, forms for purchase 
options and lease options can be provided. 

Appendices 

Information that will assist the supplier in further 
understanding of the institution can be included in 
appendices. 
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Appendix D: 

Sample Vendor Evaluation Criteria 



Sample General Vendor Review Criteria 

Background/History 

• Who started the company when, and why? 

• What were the initial products? 

• Who were the initial clients? 

• Describe growth in products, staff, and so forth. 

• What have been the changes in focus and client base? 

• What are the significant accomplishments? 

Vision/Core Values 

• What is the vision of the company? 

• What are the core principles, i.e., the three to six 
statements that define the company, that will stay the 
same regardless of internal and external change? 

Company Financial Position 

• Is the company publicly or privately held? Is informa- 
tion available to the public? 

• Does the company voluntarily disclose debt structure, 
financial projections, and planning? 

Products and Services 

• What are the key products, basic architecture, hard- 
ware platforms, languages? 

• What is the product orientation — i.e., toward what 
computing environment, solving what business 
problems? 

• What are the types of products — extent of 
customization vs. turnkey installation? 

• Is there an overview of the development process, 
testing and evaluation procedures, release schedule? 

• Are projects always or usually completed on time? 

• Are deadlines met? 

• How are budgets established? 

• What are the life cycles of products? 

• Is the market niche(s) changing? 

• What are the projections? 

• How is the need for upgrades, new products assessed? 



Facilities and Staff 

* Describe status and security of facilities. 

* Are there any plans for new facilities? 

* How many original employees were there? 

* How many of the originals remain? 

* Describe the ideal employee. 

* Describe the typical employee, e.g., education, experi- 
ence, etc. 

* How are employees hired? 

* What is the rate of staff turnover? 

* Describe the general morale of the employees. 

* Are open positions filled relatively quickly? 

* Is there competitive compensation? 

* Describe employee benefits. 

* Describe staff training, cross training. 

* Describe employee evaluation. 

* Who is promoted and why? 

* Who are the leaders in the company? 

* What is the functional expertise of the staff? 

* Do staff skills match client needs? 

Policies and Procedures 

* What are the written procedures for product develop- 
ment? 

* Are products always developed the same way? 

* How are problems tracked? 

* What are the legal procedures and policies, e.g., con- 
tracting standards? 

* Are there any extant legal complications? 

Organization and External Relationships 

* Are formal organization charts available and up to date? 

* Describe staff coordination, communication. 

* What are policies and traditions on ethics, security, 
integrity? 

* What is the management style? 

* What are the user groups? 

* What are the advisory groups? 

* How are user expectations and satisfaction surveyed, 
assessed, and/or measured? 
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Innovation and Planning 

• How are good ideas encouraged, recognized, evaluated, 
incorporated? 

• Is there any formal planning and plans (e.g., opera- 
tional, multi-year, disaster)? 

• For project planning with goals, objectives, 
deliverables, budgets, responsibilities, staffing levels, 
and deadlines — how are changes to these plans 
accommodated (change order process)? 

• How does the client participate in planning? 

Self-assessment and Quality Control 

• How is quality assured? 

• How is customer/client satisfaction measured? 

• What is the method of self-assessment/benchmarking 
with management, employees, clients? 

• Is there credibility with clients, competitors, the 
professional community? 

• Who are major competitors, and how is competition 
monitored? 

Sample Financial Module Review Criteria 

The following questions might be asked specifically about 

the supplier's financial module: 

• What are the product specifications, development 
history, and present status of the financial module? 

• What is the number of modules? 

• How are user interfaces developed? 

• What are the existing architecture, hardware plat- 
forms, databases, and software development tools? 

• What are future plans for the product's architecture, 
hardware platforms, databases, and software develop- 
ment tools? 

• Are there plans to move to an open environment? 
client/server architectures? UNIX-based products? Are 
products compliant with the Open Software 
Foundation's Distributed Computing Environment 
(DCE)? 

• What is the accounting structure? 

• Does the module take advantage of relational database 
tabular structure? 

• Is it integrated, stand-alone, or other? 

• What are the software report capabilities? Do they 
leverage database capabilities? 

• Are there adequate code documentation and user 
documentation? 

• How are user control requirements met? 

• Who is an ideal or typical customer? 



* Has the client base changed, and are changes in the 
target market anticipated? 

* How much product customization occurs? 

* Is code being changed for any reason? 

* What new functionality has come into the product, 
e.g., is an object-oriented approach anticipated, have 
graphical user interfaces been developed? 

* Is there technical support for customers, help lines, 
user group meetings, and so forth? 

* Are there team arrangements with hardware vendors? 
with customers? 

* How do staff acquire new functional expertise when 
required? 

Sample Evaluation and Partnership 
Criteria, California Lutheran University 

The criteria below were used by California Lutheran 
University in evaluating the vendors who submitted 
proposals to partner with CLU in a network project, but 
they could apply in a systems project, as well. Vendors 
were provided a description of the specific issues that had 
to be addressed in their presentation, the benefits CLU 
planned to provide as a partner, CLU's vested interest in 
the partnership, and a copy of the actual evaluation 
process steps. 

Evaluation Criteria 
Strategic Partnership 

Conformance to CLU's Mission: 

1. Has the vendor developed a preliminary plan or a list of 
potential partnership-related activities (i.e. participating 
with CLU in trade shows and academic conferences, 
teaming with CLU in innovative joint marketing ventures, 
providing grant contacts, etc.) that could help achieve 
CLU's mission through the partnership? 

2. Has the vendor committed to implementing the plan or 
participating in activities that will support CLU's mission? 

3. Are either parts of the plan or some of the proposed 
activities outside the boundaries of CLU resources, capa- 
bilities, preferred lines of business, or organizational 
culture? If yes, does this severely damage the feasibility of 
the proposed plan or set of activities? 





Conformance to the Vendor's Mission: 

1. Has the vendor clearly stated its corporate mission? 

2. Does a partnership as CLU perceives it effectively 
support the vendor's mission? If not, this is a potential 
risk that must be managed and mitigated. 

3. Has the vendor developed a preliminary plan or a list of 
potential partnership-related activities that could help 
them achieve their mission through the partnership? If the 
plan or the list of activities do not convince you that there 
is a strong correlation between the vendor's mission and a 
CLU partnership, this is a potential risk that must be 
managed and mitigated. 

4. Are either parts of the plan or the proposed activities 
outside the boundaries of CLU resources, capabilities, 
preferred lines of business, or organizational culture? If 
yes, does this severely damage the feasibility of the pro- 
posed plan or set of activities? 

Practical Partnership 

1. Are the vendor's vested interests clearly identified? 

2. Are these vested interests consistent with the vendor's 
mission statements? If not, this is a potential risk that 
must be managed and mitigated. 

3. Are the vendor's vested interests in conflict with CLU's 
vested interest or business practices? 

4. Has the vendor acknowledged CLU's vested interest and 
made a commitment to serve that vested interest? 

5. Have each partner's responsibilities and expectations 
been very specifically defined to ensure a mutual under- 
standing and agreement to the proposed responsibilities 
and expectations? 

Economic Partnership 

1. Are the financial strategies feasible within CLU's finan- 
cial capabilities? 

2. Are any of the financial strategies outside the bound- 
aries of CLU business philosophy or practices? If yes, does 
this severely damage the feasibility of the entire financial 
strategy? 

O 




3. Are the financial strategies based upon realistic financial 
projections and data? 

4. Are the explanations of the financial strategies, the data 
that support these strategies, and the revenue-sharing 
strategies clear, concise, and not open to multiple interpre- 
tations or in need of clarification? 

5. Are the revenue-sharing strategies equitable to both CLU 
and the vendor? 

6. Does the financial strategy provide for a technical and 
service solution that strongly supports CLU's mission 
statements and [project] mission statements? 

7. Does the financial strategy strongly support achieving 
the vendor's mission statements? If not, this is a potential 
risk that must be managed and mitigated. 

Partnership Criteria 

Strategic Partnership 

Conformance to CLU's Vision: 

A commitment to work within CLU's resources and 
capabilities to establish a partnership and develop a plan 
that will directly support CLU's strategic vision, which 
includes: 

• Earning distinction in the learned professions. 

• Achieving rank as an institution of first choice of 
students regionally and beyond. 

• Equipping students for meaningful lives and success- 
ful careers in the context of technological, ideological, 
and social change. 

• Providing for the professional, economic, cultural, and 
social welfare of the communities in Southern Califor- 
nia and beyond. 

• Growing into an institution of 2,200 undergraduate 
and 1,200 graduate students. 

Conformance to the Vendor's Vision: 

A commitment to work within CLU's resources and 
capabilities to establish a partnership and develop a plan 
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that will directly support the vendor's strategic vision (as 
defined by the vendor) which could include: 

• Entering or solidifying its position in the market. 

• Gaining or maintaining a significant competitive 
advantage in the market. 

• Meeting its long-term strategic goals (i.e. sales, growth 
etc.). 

• Enhancing the vendor's image in the community by 
demonstrating social responsibility. 

• Gaining regional visibility. 

• Gaining increasing exposure and credibility in the 
marketplace. 

Economic Partnership 

A commitment to work within CLU's resources and 
capabilities to establish a partnership which develops 
innovative financing strategies that support CLU's goals 
within CLU's budget while ensuring sought-after tangible 
and intangible benefits to the vendor by: 

• Graduated scales constraints of payments to meet 
CLU's budget constraints. 

• Expanding vendor opportunities as CLU grows. 

• Participating in mutual R & D of new opportunities. 

• Sharing with the vendor additional CLU revenue 
resulting from capabilities provided by vendor 
through innovative financing strategies and joint CLU/ 
vendor marketing ventures. 

• Sharing with CLU additional vendor revenues result- 
ing from joint CLU/vendor marketing ventures. 

• Developing realistic financial projections. 

• Ensuring an acceptable return on investment for each 
partner. 

• Improving CLU's grant positioning by helping estab- 
lish a track record of providing students with sought- 
after capabilities and services cost-effectively. 
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Practical Partnership 

A commitment to work with CLU to establish an honest 
and open relationship that: 

• Openly recognizes and supports each partner's vested 
interest. 

* Specifically details each partner's responsibilities and 
expectations. 
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Appendix E: 

Sample Measurement Systems 

The two approaches included in this appendix are provided simply as examples of measurement methods that have been 
used successfully in systems projects. Neither may be appropriate for your systems project. 



Model Used toy Sinclair Community College i 

Phase I - Application Requirements - Total of 65%: 

Financial Management - 60% = to (.65x.60) 39% of Phase I 



Phase I - Technical Requirements - 35% 

Hardware - 25% = to (.35x.25) 8.75% of Phase I 



General Ledger 


20% 


Support 200 users 


25% 


Purchasing/Receiving 


15% 


Adequate Performance 


25% 


Accounts Payable 


15% 


Printing 


10% 


Budgeting 


15% 


Backup Services 


10% 


Decision Support 


15% 


UPS/Line Conditioning 


10% 


Central Stores 


2% 


Upgrades 


5% 


Bookstore 


3% 


Academic Computing 


5% 


Fixed Assets 


5% 


General Requirements 


4% 






Training 


2% 


man Resources/Payroll - 


40% = to (.65x.40) 26% of Phase I 


Documentation 


2% 


Human Resources 


45% 


Support 


2% 


Payroll 


45% 


System Security 


10% 


General Requirements 


4% 






Training 


2% 


Software - 75% = to (.35x.75) 


26.25 i 


Documentation 


2% 


Database Management 


30% 


Support 


2% 


Query Report Writer 


10% 


General Requirements 


4% 


Development Tools 


20% 


Training 


2% 


Development Language 


15% 


Documentation 


2% 


Connectivity 


5% 


Support 


2% 


General Requirements 


4% 






Training 


2% 






Documentation 


2% 






Support 


2% 



*The original of this model included modules for the Student Information System and the Alumni/Development System. 
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Phase II Evaluation 

Implementation 
* Implementation Plan 
References 
Ability to Complete 
Financial Stability 
Comfort Level 

Costs 

Application Software 

Hardware 

Systems Software 

Other Costs: 

Custom software 
Partnership costs 
Special or temporary staffing 
Conversion programming 
Keying or other support 
Training and documentation 
Hardware or software maintenence 
for two systems during conversion 
Changes to infrastructure (cabling, etc.) 
Project contingency 

* The implementation plan includes overall 
evaluation of training, implementation, documen- 
tation, and support in addition to individual 
evaluations of the implementation plan provided 
by specific application and technical groups. 



Ann adteimMive model for deffmMg 
measumres 

Vendor Firm Analysis 

(worth 10 percent of total evaluation) 

4% References (telephone questionnaire) 
2% Client base 

2% Firm's financial stability (both current 
and five-year trend) 

1% Experience 
1% Employee profile 

Applications Software Technical Analysis 
(worth 30 percent of total evaluation) 

5% Applications software standards 
4% Database standards 
4% Documentation 
4% Security and access control 
4% Training 

3% Compatibility and general technologies 
3% Continuing support 
3% Installation services 

Applications Software Functional Analysis 
(worth 60 percent of total evaluation) 

Financial Management Systems 
19% General ledger 
9% Accounts payable 
9% Accounts receivable 
9% Available funds 
9% Budgets 

9% Grants and contracts accounting/ 
sponsored program tracking 
9% Loan administration 
9% Property control 
9% Purchasing 
9% Student accounts 
Human Resources 
50% Payroll 
50% Personnel 



Appendix F: Corporate Products and Services 



Listed below are corporate members of NACUBO and 
CAUSE that have financial application products or consult- 
ing services related to financial systems acquisitions and 
implementations. This is not intended to be an all-encom- 
passing' list, that is, it does not include companies with 
peripheral products related to financial systems (such as 
financial aid, cashiering, smart cards) or companies with 
products that would be used in retooling in-house devel- 
oped systems (such as integration or development tools, 



database management systems, data warehouse develop- 
ment tools, middleware, and so forth). Your project 
management team can learn more about most of the 
corporations and firms listed below, as well as many others 
with peripheral products, by visiting the CAUSE Corporate 
Member Directory on the CAUSE World Wide Web server 
(http://cause-www.colorado.edu/member-dir/cusclass/ 
corporation_members.html). 



ABT, Inc. 

4631 West Chester Pike 
Newtown Square, PA 19073 
phone: 800-220-2281 
fax: 610-359-1351 
http://www.abtcampus.com/ 

American Management Systems 

4050 Legato Road 

Fairfax, Virginia 

phone: 703-267-8147 

fax: 703-267-2196 

http://www.amsinc.com/ 

Andersen Consulting 
45 South Seventh Street 
Minneapolis, MN 55402 
phone: 612-334-4512 
fax: 612-334-4710 
http://www.ac.com/ 

Bi-Tech Software, Inc. 

890 Fortress Street 
Chico, CA 95973 
phone: 916-891-5281 
fax: 916-891-4816 
http://www.bi-tech.com/ 



Business Information Technology 
1800 Sutter Street, Suite 770 
Concord, CA 94520 
phone: 510-671-0595 
fax: 510-671-2523 
http://www.bitcorp.com/bitcorp 

Buzzeo, Inc. 

Corporate Office 

13951 N. Scottsdale Road, Ste. 111A 
Scottsdale, AZ 85254 
phone: 602-596-2484 
fax: 602-596-2486 
http://www.buzzeo.com/ 

Campus America 
900 Hill Avenue, Suite 205 
Knoxville, TN 37915-2523 
phone: 615-523-9506 
fax: 615-525-5628 
http://www.campus.com/ 

CARS Information Systems 
Corporation 
Corporate Headquarters 
4000 Executive Park Drive 
Cincinnati, OH 45241-4009 
phone: 513-563-4542 
fax: 513-733-8990 

http://www.carsinfo.com/ X X 5 



CASEware Technology, Inc. 

3149 N. Highway 89, Suite 8 
Ogden, Utah 84404 
phone: 801-782-0404 
fax: 801-782-3317 
http://intele.net:80/~caseware/ 

CMDS, Inc. / 

1661 Virginia Avenue 
Harrisonburg, VA 22801 
phone: 800-999-2637 
fax: 540-432-5275 
http://www.product.com/cmds/ 

Computer Associates 

One Computer Associates Plaza 

Islandia, NY 11788-7000 

phone: 516-342-5224 

fax: 516-342-6864 

http://www.cai.com/ 

Coopers & Lybrand 
One Post Office Square 
Boston, MA 02109 
phone: 617-478-5211 
fax: 617-478-5900 
http://www.colybrand.com/ 
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Datatel, Inc. 

100 Spear Street/Suite 1410 
San Francisco, California 94105 
phone: 415-957-9000 or 
800-969-9002 
fax: 703-968-4540 
http://www.datatel.com/ 

Deloitte & Touche LLP 

2101 Webster Street, Suite 2000 

Oakland, CA 94612 

phone: 510-287-2804 

fax: 510-273-2310 

http://www.dttus.com/ 

EDUTECH International 
120 Mountain Avenue 
Bloomfield, Connecticut 06002 
phone: 203-242-3356 
fax: 860-242-9634 

Ernst & Young LLP 
1225 Connecticut Avenue, N.W. 
Washington, DC 20036 
phone: 202-327-6356 
fax: 202-327-6227 

Gartner Group 
56 Top Gallant Road 
Stamford, CT 06902 
phone: 203-316-1111 
fax: 203-975-6576 
http://www.gartner.com/ 

Grant Thornton 

1660 Lincoln Street, Suite 2600 

Denver, CO 80264 

phone: 303-861-5555 

fax: 303-894-9620 

Hyperion Software 
900 Long Ridge Road 
Stamford, CT 06902 
phone: 203-703-3000 
fax: 203-968-9319 
http://www.hysoft.com/ 



IBM 

Higher Education 
1133 Westchester Avenue 
White Plains, NY 10604 
phone: 914-642-6035 
phone: 914-642-6848 
http://ike.engr.washington.edu/ 

Kaludis Consulting Group 
2505 Hillsboro Road, Suite 302 
Nashville, TN 37212 
phone: 615-297-3880 
fax: 615-297-3884 

KPMG Peat Marwick 
Higher Education Technology 
and Operations Practice 
P.O. Box 4545 
Houston, TX 77210-4545 
phone: 713-221-0116 
fax: 713-221-0329 
http://www.kpmg.com/ 

Oracle Corporation 

222 Berkeley Street, Suite 1200 

Boston, MA 02116 

phone: 617-437-8369 

fax: 617-247-2847 

http://www.oracle.com/ 

PeopleSoft, Inc. 

Corporate Headquarters 

4440 Rosewood Drive 

Pleasanton, California 94588-3031 

phone: 510-225-3000 

fax: 510-225-3100 

info@peoplesoft.com 

http://www.peoplesoft.com/ 

Pinnacle Software Corporation 
180 WillowBrook Office Park 
Fairport, NY 14450 
phone: 716-381-2750 
fax: 716-381-5211 
http://pinsunl.sctcorp.com/ 
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Price Waterhouse LLP 
3110 Fairview Park Drive 
Falls Church, VA 22042 
phone: 703-641-5522 
fax: 703-646-5568 

Quodata Corporation 
One Union Place 
Hartford, CT 06103 
phone: 203-728-6777 
fax: 203-247-0249 
http://www.quodata.com/ 

SAP America, Inc. / 

701 Lee Road 

USA- Wayne, PA 19087 

phone: 800-USA-1SAP 

fax: 610-725-4555 

http://www.sap.com/ 

Software AG 

11190 Sunrise Valley Drive 
Reston, VA 22091 
phone: 703-391-6704 
fax: 703-391-8290 
http://www.sagus.com/ 

Systems & Computer Technology 
Corporation (SCT) 

2 Country View Road 
Malvern, PA 19355 
phone: 610-647-5930 
fax: 610-640-5102 
http://www.sctcorp.com/ 

USA Group TRG, Inc. 

4343 East Camelback Road 
Phoenix, AZ 85018 
phone: 602-808-4000 
fax: 602-808-4001 
http://www.trglink.com/ 

Virchow Krause & Company 
1100 TCF Tower 
121 South Eighth Street 
Minneapolis, MN 55402-2848 
phone: 612-341-3030 
fax: 612-341-9838 
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